bugGNU Octave - Bugs: bug #39698, imread test crashes Octave

 
 

bug #39698: imread test crashes Octave

Submitter:  Carlo de Falco <cdf>
Submitted:  Mon 05 Aug 2013 10:38:37 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 04 Sep 2013 05:34:39 PM UTC, comment #23: 

Well, I'll mark it as fixed then.

Carnë Draug <carandraug>
Group Member
Wed 04 Sep 2013 11:44:47 AM UTC, comment #22: 

Hi I finally managed to build again with a new version of GraphicsMagick.

I am now using the latest version provided by MacPorts with the +q32 variant enabled and I also do not see the crash anymore.

I also seem to be able to load all the png's attached to this thread.

Carlo de Falco <cdf>
Group Member
Wed 04 Sep 2013 11:26:18 AM UTC, comment #21: 

I'm not sure the problem exists for me anymore.  Could it just be that something on my end changed (i.e. macports updated something?)

Ben Abbott <bpabbott>
Group Member
Wed 04 Sep 2013 03:52:36 AM UTC, comment #20: 

Well, that's weird. Both imread and imfinfo work fine with that file on my computer. I don't know what to do next. Here's a resume for the future then:

  • this seems to occur in a Mac, with a file created in a Mac. A file created in Linux will not cause an error in a Mac, and a file created in a Mac will not cause an error in Linux.
  • only happens with imfinfo (imread works fine)
Carnë Draug <carandraug>
Group Member
Wed 04 Sep 2013 01:02:13 AM UTC, comment #19: 

I've attached the file.  What is the default precision used by fwrite?  Should it be int8?




Ben Abbott <bpabbott>
Group Member
Wed 04 Sep 2013 12:03:08 AM UTC, comment #18: 

No. I'm sorry for the confusion.

I want to say to use the fwrite test on the example, and send me the png that your system generates. I'll then try to see if imfinfo fails on my side, trying to read the file you write. Basically, send me the file that the following snippet generates:


vpng = [ ...
  137,  80,  78,  71,  13,  10,  26,  10,   0,   0, ...
    0,  13,  73,  72,  68,  82,   0,   0,   0,   3, ...
    0,   0,   0,   3,   8,   2,   0,   0,   0, 217, ...
   74,  34, 232,   0,   0,   0,   1, 115,  82,  71, ...
   66,   0, 174, 206,  28, 233,   0,   0,   0,   4, ...
  103,  65,  77,  65,   0,   0, 177, 143,  11, 252, ...
   97,   5,   0,   0,   0,  32,  99,  72,  82,  77, ...
    0,   0, 122,  38,   0,   0, 128, 132,   0,   0, ...
  250,   0,   0,   0, 128, 232,   0,   0, 117,  48, ...
    0,   0, 234,  96,   0,   0,  58, 152,   0,   0, ...
   23, 112, 156, 186,  81,  60,   0,   0,   0,  25, ...
   73,  68,  65,  84,  24,  87,  99,  96,  96,  96, ...
  248, 255, 255,  63, 144,   4,  81, 111, 101,  84, ...
   16,  28, 160,  16,   0, 197, 214,  13,  34,  74, ...
  117, 213,  17,   0,   0,   0,   0,  73,  69,  78, ...
   68, 174,  66,  96, 130];
   fid = fopen ("send-this-file.png", "wb");
   fwrite (fid, vpng);
   fclose (fid);


Carnë Draug <carandraug>
Group Member
Tue 03 Sep 2013 11:27:56 PM UTC, comment #17: 

So, I should fread() an existing png and then attempt to use fwrite() to create a duplicate?

Ben Abbott <bpabbott>
Group Member
Tue 03 Sep 2013 11:05:58 PM UTC, comment #16: 

No. I really meant fwrite(). The correct syntax to write an image file is indeed to use imwrite(). But the failing test uses fwrite(). My guess is that this is to avoid possible bugs in imwrite interfering with the test in imread. I don't know how it was done, possibly by creating the png file the correct way, and then using fread() to get a vector of doubles that could replicate it. You will notice that was written in the file has no obvious connection to the matrix that imread returns. Does that make sense to you?

Carnë Draug <carandraug>
Group Member
Tue 03 Sep 2013 07:19:09 PM UTC, comment #15: 

You mentioned fwrite().  Did you intend that I use imwrite()?  I've attached the result of


tmp = imread ('tmp.png');
imwrite (tmp, 'foo', 'png')



Ben Abbott <bpabbott>
Group Member
Tue 03 Sep 2013 05:53:34 PM UTC, comment #14: 

I'm not familiar with the image stuff.  What is the proper syntax to write the png file?

Ben Abbott <bpabbott>
Group Member
Tue 03 Sep 2013 02:47:41 PM UTC, comment #13: 

Ok. So my theory is since fwrite() behaves differently in machines with different architectures, the test was writing different files. Could you send me the tmp.png that you system writes to test on mine? If this is indeed the cause of the problem, I'm guessing it can be fixed by specifying the architecture on fopen and fwrite.

Carnë Draug <carandraug>
Group Member
Tue 03 Sep 2013 02:39:07 PM UTC, comment #12: 

You are correct, I used imshow ().  imread() does return the correct matrix.


tmp = imread ('tmp.png')
tmp =

ans(:,:,1) =

    0  255    0
  255  237  255
    0  255    0

ans(:,:,2) =

    0  255    0
  255   28  255
    0  255    0

ans(:,:,3) =

    0  255    0
  255   36  255
    0  255    0


Ben Abbott <bpabbott>
Group Member
Tue 03 Sep 2013 02:35:08 PM UTC, comment #11: 

That is the correct image if displayed with imshow. I get the same. Use image ou imagesc to get the matrix displayed. The important is that imread returns the following matrix from that png:


ans(:,:,1) =

    0  255    0
  255  237  255
    0  255    0

ans(:,:,2) =

    0  255    0
  255   28  255
    0  255    0

ans(:,:,3) =

    0  255    0
  255   36  255
    0  255    0


If imread returns that matrix then the problem lies somewhere on fwrite since that's the only thing that changed now.

Carnë Draug <carandraug>
Group Member
Tue 03 Sep 2013 02:24:41 PM UTC, comment #10: 

I can read and display it without crashing, but the result isn't correct (see attached)


Ben Abbott <bpabbott>
Group Member
Tue 03 Sep 2013 01:53:05 PM UTC, comment #9: 

Then the problem was that imfinfo fails in Mac, when trying to read a file that is very weird to start with (the matrix that was written with fwrite is the one in the imread test).

imfinfo gets more than just height and width of the image. It tries to get a lot of metadata that simply does not exist in the file.

I don't know what we're doing wrong. Codewise everything looks correct to me and this only happens in Mac. The only thing that looks wrong is the actual "image" file. Can you try imfinfo with the one I attached? It's the same file, but written by my system.


Carnë Draug <carandraug>
Group Member
Tue 03 Sep 2013 12:37:58 PM UTC, comment #8: 

Yes. I can read the example you liked to (with q8) and display it as well (see attached)


Ben Abbott <bpabbott>
Group Member
Tue 03 Sep 2013 03:12:36 AM UTC, comment #7: 

But does it fail with an actual png image file such as https://upload.wikimedia.org/wikipedia/en/7/70/Example.png ?

Carnë Draug <carandraug>
Group Member
Mon 02 Sep 2013 04:59:22 PM UTC, comment #6: 

Yes. It fails.


vpng = [ ...
  137,  80,  78,  71,  13,  10,  26,  10,   0,   0, ...
    0,  13,  73,  72,  68,  82,   0,   0,   0,   3, ...
    0,   0,   0,   3,   8,   2,   0,   0,   0, 217, ...
   74,  34, 232,   0,   0,   0,   1, 115,  82,  71, ...
   66,   0, 174, 206,  28, 233,   0,   0,   0,   4, ...
  103,  65,  77,  65,   0,   0, 177, 143,  11, 252, ...
   97,   5,   0,   0,   0,  32,  99,  72,  82,  77, ...
    0,   0, 122,  38,   0,   0, 128, 132,   0,   0, ...
  250,   0,   0,   0, 128, 232,   0,   0, 117,  48, ...
    0,   0, 234,  96,   0,   0,  58, 152,   0,   0, ...
   23, 112, 156, 186,  81,  60,   0,   0,   0,  25, ...
   73,  68,  65,  84,  24,  87,  99,  96,  96,  96, ...
  248, 255, 255,  63, 144,   4,  81, 111, 101,  84, ...
   16,  28, 160,  16,   0, 197, 214,  13,  34,  74, ...
  117, 213,  17,   0,   0,   0,   0,  73,  69,  78, ...
   68, 174,  66,  96, 130];
   fid = fopen ("tmp.png", "wb");
   fwrite (fid, vpng);
   fclose (fid);
 A = imfinfo ("tmp.png");
warning: your version of GraphicsMagick limits images to 8 bits per pixel
octave(32686,0x7fff74e44960) malloc: *** error for object 0x7fff75650860: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug


Ben Abbott <bpabbott>
Group Member
Mon 02 Sep 2013 02:21:00 PM UTC, comment #5: 

That may be because I changed imread to no longer call imfinfo. Does the following fails?


vpng = [ ...
  137,  80,  78,  71,  13,  10,  26,  10,   0,   0, ...
    0,  13,  73,  72,  68,  82,   0,   0,   0,   3, ...
    0,   0,   0,   3,   8,   2,   0,   0,   0, 217, ...
   74,  34, 232,   0,   0,   0,   1, 115,  82,  71, ...
   66,   0, 174, 206,  28, 233,   0,   0,   0,   4, ...
  103,  65,  77,  65,   0,   0, 177, 143,  11, 252, ...
   97,   5,   0,   0,   0,  32,  99,  72,  82,  77, ...
    0,   0, 122,  38,   0,   0, 128, 132,   0,   0, ...
  250,   0,   0,   0, 128, 232,   0,   0, 117,  48, ...
    0,   0, 234,  96,   0,   0,  58, 152,   0,   0, ...
   23, 112, 156, 186,  81,  60,   0,   0,   0,  25, ...
   73,  68,  65,  84,  24,  87,  99,  96,  96,  96, ...
  248, 255, 255,  63, 144,   4,  81, 111, 101,  84, ...
   16,  28, 160,  16,   0, 197, 214,  13,  34,  74, ...
  117, 213,  17,   0,   0,   0,   0,  73,  69,  78, ...
   68, 174,  66,  96, 130];
   fid = fopen ("tmp.png", "wb");
   fwrite (fid, vpng);
   fclose (fid);
   A = imfinfo (filename);


If this fails but imfinfo with an actual png file passes, then the problem was in the actual test.

Carnë Draug <carandraug>
Group Member
Mon 02 Sep 2013 12:55:10 PM UTC, comment #4: 

I uninstalled GraphicsMagick+q8 and then reinstalled (i.e. new build and install).  This time, there is no failure.  I have no idea why.

+verbatiim+
test imread
warning: your version of GraphicsMagick limits images to 8 bits per pixel
PASSES 1 out of 1 test
-verbatim+

Ben Abbott <bpabbott>
Group Member
Mon 02 Sep 2013 02:00:19 AM UTC, comment #3: 

If changing quantum depth fixes the problem is very weird if it's also true that the origin of the problem is in imfinfo.

Does imfinfo and imread using +q8 causes any trouble when using a real png file, or does it only fails with the png file on the imread test (which I'm unsure if it counts as a an actual png file).

Carnë Draug <carandraug>
Group Member
Sun 01 Sep 2013 09:03:36 PM UTC, comment #2: 

The 32 bit variant also works "+q32"

Ben Abbott <bpabbott>
Group Member
Sun 01 Sep 2013 08:35:35 PM UTC, comment #1: 

Carlo,

Are you using macports?  If so, when I change the variant to +q16, "test imread" passes for me.

Ben Abbott <bpabbott>
Group Member
Mon 05 Aug 2013 10:38:37 AM UTC, original submission:  



>> test imread
warning: your version of GraphicsMagick limits images to 8 bits per pixel
octave(15697,0x7fff75b1b180) malloc: *** error for object 0x7fff7701d570: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6


running in a debugger I get the following bactrace:


>> imread /var/tmp/oct-zQ12fd.png
Reading symbols for shared libraries .......... done
warning: your version of GraphicsMagick limits images to 8 bits per pixel
octave(16412,0x7fff75b1b180) malloc: *** error for object 0x7fff7701d570: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
0x00007fff91581212 in __pthread_kill ()
(gdb) bt
#0  0x00007fff91581212 in __pthread_kill ()
#1  0x00007fff87bd5b54 in pthread_kill ()
#2  0x00007fff87c19dce in abort ()
#3  0x00007fff87bed9b9 in free ()
#4  0x0000000107703e26 in F__magick_finfo__ ()
Previous frame inner to this frame (gdb could not unwind past this frame)


Carlo de Falco <cdf>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #29000:  send-this-file.png added by bpabbott (155B - image/png)
file #28998:  foo.png added by bpabbott (83B - image/png)
file #28994:  tmp-macosx.png added by bpabbott (40KiB - image/png)
file #28993:  tmp.png added by carandraug (155B - image/png - file written during imread test in a x86_64 GNU/Linux system)
file #28991:  Example.png added by bpabbott (139KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by cdf (Submitted the item)
  • -email is unavailable- added by cdf
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-04 carandraug StatusNone Fixed
        Open/ClosedOpen Closed
    2013-09-04 bpabbott Attached File- Added send-this-file.png, #29000
    2013-09-03 bpabbott Attached File- Added foo.png, #28998
    2013-09-03 bpabbott Attached File- Added tmp-macosx.png, #28994
    2013-09-03 carandraug Attached File- Added tmp.png, #28993
    2013-09-03 bpabbott Attached File- Added Example.png, #28991
    2013-08-05 cdf Carbon-Copy- Added carnë draug <carandraug@octave.org>

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code