Legacy ImageMagick Discussions Archive

Hi,
I have a strange segmentation fault when I draw text with a set strokecolor.
The segmentation fault occurs when I use ImageMagick code in combination with OpenCV or Qt.

I make it simple. Consider, for instance, your piddle.cpp demo in which I just changed the lines drawing text.
Here it is the changed part:
...
//
// Draw text.
//
drawList.push_back(DrawableFillColor("green"));
drawList.push_back(DrawableStrokeColor(Color("black"))); // SET COLOR!!!
drawList.push_back(DrawableStrokeWidth(1)); // SET WIDTH!!!
drawList.push_back(DrawablePointSize(24));
drawList.push_back(DrawableTranslation(30,140));
drawList.push_back(DrawableRotation(45.0));
drawList.push_back(DrawableText(0,0,"This is a test!"));
...

The code perfectly compiles and runs without other changes.
The segmentation fault occurs when i just add at the top of the main function this single line (OpenCV function):

cvNamedWindow("awindow", CV_WINDOW_AUTOSIZE); // prepare a window where to draw OpenCV stuff

In order to have the code compiled I also add at the top of the program this required include

#include "highgui.h"

This my gdb print:

[Thread debugging using libthread_db enabled]
[New Thread 0xb3e02a00 (LWP 28118)]
[New Thread 0xb3b65b90 (LWP 28121)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb3e02a00 (LWP 28118)]
TraceBezier (primitive_info=0xb32edd28, number_coordinates=2432)
at magick/draw.c:1673
1673 primitive_info->coordinates=1;
Current language: auto; currently c

For this code, the segmentation fault disappears in any of the following cases:
1) I put the openCV istruction cvNamedWindow() at the end of the 'try' block (after the imagemagick drawing lines).
2) I comment the DrawableStrokeColor line
3) I leave the strokeColor unset.

The same problem also occurs when i use Qt for drawing imagemagick stuff. Even in this case, gdb reports error at the same line of the file magick/draw.c.
The problem seems related to setting a strokeColor for drawing text. Conversely, setting a strokeColor for drawing other objects does not generate errors!

Thanks in advance for your help.

- Xfly

Hi,
I am putting my nose in the file magick/draw.c.
The problem seems to be in the function TracePath() in the case 'c' 'C' where
the function TraceBezier() is called.

In the function TraceBezier(), around line 5087 i made the following changes
/*
Bezier curves are just short segmented polys.
*/
p=primitive_info;
for (i=0; i < (long) control_points; i++)
{
TracePoint(p,points);
p+=p->coordinates;
// START MY CHANGE ****************************
if( (p - primitive_info) >= number_coordinates )
{
p-=p->coordinates;
break;
}
// END MY CHANGE ****************************
}

In my trials, I noticed that whith these changes:
- when I do not insert the opencv function, the resulting plot seems correct
- when I insert the opencv function, these changes prevent a segmentation fault but the resulting plot is not correct!

- Xfly

Hey,
FINALLY I FOUND THE BUG!

The problem is in the function

static unsigned long TracePath(PrimitiveInfo *primitive_info,const char *path) (see the file magick/draw.c)

Its argument "const char *path" is assumed to store a sequence of heterogenous data: chars and floats.
This data sequence is generated by the calling function DrawImage() (see the same file magick/draw.c).
The main point is that, in this sequence of data (stored by the argument char* path), the character ',' is assumed to act as a separator between pair of consecutive data.

Now, the problem is that when I use Qt or OpenCV, the local representation of the float numbers is changed.
That is, decimal commas are used instead of decimal points!
Consequently, the internal parser of the function TracePath() fails
since it is not able to distinguish between decimal commas and separating commas!!!
A segmentation fault follows.

MY SOLUTION to this problem is to add the following line

std::locale::global(std::locale("C"));

before any call to the ImageMagick functions.

I think the use of commas ',' as data separator is not very robust!

Ciao

by the way...thank you for your many many many replies

We respond to all bug reports but there are several other reports we are currently attending to. We should be able to get to this one within a week.