Legacy ImageMagick Discussions Archive

I've been stuck on this for a while now, and could really use some help. I'm in the process of converting some old C++ code to 64-bit on AIX 6.1, and have downloaded and built ImageMagick ver 6.8.7 for this project. (created both 32 and 64 bit libs) The code is pretty simple in it's use of ImageMagick, the images are scanned documents in TIFF format, and the program needs to make a JPEG thumbnail view of the image. It loads the image from a Blob, creates a "Image" object using it, tries to set the image format to Jpeg and reduces the size, and then writes it out to another Blob. (the Blobs are eventually pushed into a database table, but that's not relevant here)

The problem I'm having is that I can compile and link the code, create the Blob, create the Image object from the Blob, and then I get a segmentation fault when I attempt to set the Image to JPEG. ( Image.magick("JPEG") ) it's not specific to JPEG either, it happens with any image format I try to set. I'm able to read the attributes of the Image object, but a format change or even a call to write to a file causes the seg fault.

The exact message is:
Segmentation fault in . at 0x7c0802a6f800 ($t1)
0x7c0802a6f800 (???) Unreadable instruction at address 0x7c0802a6f800

The 32-bit version of this code is working fine with an older version of ImageMagick, and the images I'm using are valid. I did attempt to do the TIFF to JPEG conversion with the "convert" tool, and it works just fine. I could try to post some code snippets, but I'm not doing anything different than the ImageMagick sample code does. One minor difference is that it's using the old deprecated auto_ptr to create the Magick::Image objects, but it was doing that in the 32-bit version too.

The machine I'm on has plenty of memory for this operation, the doc image is only about 88k as a TIFF, 1.6mb as a Jpeg, and I've tried upping the ulimits with no change in behavior.

Any clues as to what my problem might be, or at least something else I can look at to try to diagnose this? One thing that comes to mind, is if I need the "coders" for the api to work properly? I'm not sure how to get them, they exist in the build directory, but they aren't getting copied when I do a make install.

Thanks in advance,
--Mike

A little more info, not sure if it helps or not. I rebuilt ImageMagick again, this time using -with-modules on in the configure, and it has now built the modules and installed them.

If I run "convert -list configure", both jpeg and tiff are listed under DELEGATES.(they were before too) But now when I run my application, I get error messages saying that it can't load the tiff.la coder, and it still seg faults. I opened up permissions on the directory with no change. If I run "convert -debug configure,module logo: image.tif", it gets to the point of loading the "magick.la" coder and then just sits there, doesn't crash, doesn't complete, doesn't create the image, nothing. I looked at it in top, and it's idle, and using about 2mb of ram.

--Mike

Try a fresh install. That means deleting the installed folders such as /usr/local/lib/ImageMagick-6. Also delete your build source folders. Now start from scratch, build and install. Do you still get the same fault?

Okay, I'll try that, I'm about at the point of giving up anyway. I think part of the issue is that this box I'm on currently has a 32-bit version of the 6.8.0.10-1 libraries installed as an RPM (prebuilt from Perzl.org) The 64-bit version that I built on 6.8.7 is under /usr/local/ImageMagick.6.8.7-64, and we were trying to get these to co-exist together. I'm going to try to remove the 32-bit version for now, to see if I can get the 64-bit working. Is there any way to build both the 32 and 64 versions together, and have a combined archive file? (supported under AIX)

Along with this seg fault, I have another weirdness that is occurring where I can't compile an executable with the ImageMagick libraries, when I try, I get an undefined symbol error on Image.magick and Image.write. I don't see this error when I build my library that includes ImageMagick. (It doesn't work though, which makes me suspicious that the compiler just isn't reporting the problem.) I am using the exact same includes and library path settings for both, and they are both built in the same cmake file. I'm hoping both these issues clear up with a refresh.

Also, is there any issue with the library name decoration in AIX? If I give Xlc the actual library names, Magick++-6.Q16, I get an error saying the file contains an incorrect file suffix. I have had to create symbolic links to the libraries in order to get rid of this error.

--Mike

I've wiped out any previous trace of ImageMagick from the server, and downloaded the latest version of the source, configured and built the libraries, and put them in my temporary installroot. I have pointed my build files at the new libraries, and I still can't get the application I've wrote to compile. It is still failing with an "Undefined Symbol" error on Image::write and Image::magick. (I'm doing an Image::magick("JPEG") and Image::write("imageOut.jpg") call)

The library that I have will compile, but I'm sure it won't work, as I suspect it's probably missing these symbols too, but the XLc linker just isn't notifying me.

The libraries exist, they are in the library search path that I'm supplying on the compile line, and they are accessible. It is resolving other symbols, for instance, if I do a image.write(&blobOut) call, it compiles fine. I'm am at a loss for what I'm doing wrong.

--Mike

To put this issue to rest, I have finally been able to get this to work.

The problem was that some of my libraries were compiled with -D_LARGE_FILE support turned on, which results in string arguments being decorated with the "_LFS_ON" identifier as in "const std::_LFS_ON::basic_string". Since configure compiled the ImageMagick library with large file support turned off, the symbols didn't match what my code thought it should be looking for. Once I removed the large file support definition, the symbols were able to resolve, and the function calls worked. The seg faults were most likely caused by the undefined symbol issue, since some of our code has to compile with -berok on to avoid link errors with some older libraries. (Don't ask, this stuff is 20 years old and reliant on a partially broken copy of IBM's IOC library. )

Thanks!
--Mike