bugGNU Octave - Bugs: bug #38280, imfinfo() crashes on 64 bit, but...

 
 

bug #38280: imfinfo() crashes on 64 bit, but not 32 bit builds

Submitted by:  None
Submitted on:  Thu 07 Feb 2013 12:51:59 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Crash
Status: Need InfoAssigned to: None
Originator Name: Alexander HansenOriginator Email: -unavailable-
Open/Closed: OpenRelease: 3.6.3
Operating System: Mac OS

Add a New Comment (Rich MarkupRich 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)

Mon 11 Feb 2013 08:55:42 PM UTC, comment #24:

I'll go ahead and summarize what the situation is as I currently know it:

1) The issue occurs for any OS X from 10.5-10.8.
2) It occurs for every of graphicsmagick and imagemagick version that I've tried.
3) Attempting to get the "TileName" and "View" parameters _magic_finfo_() (DLD_FUNCTIONS/__magick_read__.cc) leads to malloc() errors.
3A) On 64-bit (x86_64) builds Octave panics.
3B) On other builds it is able to recover.

Alexander Hansen <alexkhansen>
Mon 11 Feb 2013 07:42:28 PM UTC, comment #23:

No change when playing with different imagemagick or graphicsmagick versions, either. I tried

GraphicsMagick: 1.3.12, 1.3.17
ImageMagick: 6.7.9, 6.8.1.10

Alexander Hansen <alexkhansen>
Fri 08 Feb 2013 12:26:26 AM UTC, comment #22:

Apparently the pair of malloc() errors in the output my 32-bit setup were also due to complaints about TileName and View. I'm not sure why in that case there wasn't a panic.

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 10:23:49 PM UTC, comment #21:

And after playing around a bit, I found that if I comment out the "TileName" and "View" items in _magick_finfo_() then imfinfo() works for me:

> imfinfo("/Users/hansen/test.jpg")

ans =

scalar structure containing the fields:

Filename = /Users/hansen/test.jpg
FileModDate = 5-Feb-2013 21:01:27
FileSize = 26699
Height = 241
Width = 241
BitDepth = 8
Format = JPEG
LongFormat = Joint Photographic Experts Group JFIF format
XResolution = 0
YResolution = 0
TotalColors = 68
AnimationDelay = 0
AnimationIterations = 0
ByteOrder = undefined
Gamma = 0
Matte = 0
ModulusDepth = 8
Quality = 75
QuantizeColors = 256
ResolutionUnits = undefined
ColorType = grayscale

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 09:19:02 PM UTC, comment #20:

OK. I've got some line numbers and values now:

(gdb) bt
#0 0x00007fff8ff15212 in __pthread_kill ()
#1 0x00007fff884feaf4 in pthread_kill ()
#2 0x00007fff88542dce in abort ()
#3 0x00007fff88516959 in free ()
#4 0x000000010af10836 in F__magick_finfo__ (args=@0x1074afd30) at DLD-FUNCTIONS/__magick_read__.cc:1114
#5 0x00000001004fb8e2 in octave_builtin::do_multi_index_op (this=0x10760e560, nargout=1, args=@0x1074afd30, lvalue_list=0x0) at ov-builtin.cc:131
#6 0x00000001004fb486 in octave_builtin::subsref (this=0x10760e560, type=@0x7fff5fbfbf40, idx=@0x7fff5fbfc128, nargout=1, lvalue_list=0x0) at ov-builtin.cc:64
#7 0x00000001004fb2ae in octave_builtin::subsref (this=0x10760e560, type=@0x7fff5fbfbf40, idx=@0x7fff5fbfc128, nargout=1) at ov-builtin.cc:47
#8 0x00000001004fbeb9 in octave_builtin::subsref (this=0x10760e560, type=@0x7fff5fbfbf40, idx=@0x7fff5fbfc128) at ov-builtin.h:55
#9 0x00000001005c61ae in octave_value::subsref (this=0x7fff5fbfc140, type=@0x7fff5fbfbf40, idx=@0x7fff5fbfc128, nargout=1) at ov.cc:1201
#10 0x00000001005c6315 in octave_value::subsref (this=0x7fff5fbfc140, type=@0x7fff5fbfbf40, idx=@0x7fff5fbfc128, nargout=1, lvalue_list=0x0) at ov.cc:1214
#11 0x0000000100681d95 in tree_index_expression::rvalue (this=0x1074a3460, nargout=1, lvalue_list=0x0) at pt-idx.cc:413
#12 0x0000000100680e5c in tree_index_expression::rvalue (this=0x1074a3460, nargout=1) at pt-idx.cc:284
#13 0x0000000100682160 in tree_index_expression::rvalue1 (this=0x1074a3460, nargout=1) at pt-idx.cc:425
#14 0x000000010066bc04 in tree_simple_assignment::rvalue1 (this=0x1074a3530) at pt-assign.cc:210
#15 0x000000010067a313 in tree_evaluator::visit_statement (this=0x100f5b4e0, stmt=@0x1074a2cc0) at pt-eval.cc:736
#16 0x00000001006a0fd1 in tree_statement::accept (this=0x1074a2cc0, tw=@0x100f5b4e0) at pt-stmt.cc:151
#17 0x000000010067a572 in tree_evaluator::visit_statement_list (this=0x100f5b4e0, lst=@0x1074aca00) at pt-eval.cc:772
#18 0x00000001006a1321 in tree_statement_list::accept (this=0x1074aca00, tw=@0x100f5b4e0) at pt-stmt.cc:215
#19 0x000000010067ad8d in tree_evaluator::visit_unwind_protect_command (this=0x100f5b4e0, cmd=@0x1074afb70) at pt-eval.cc:1003
#20 0x000000010067c6c1 in tree_unwind_protect_command::accept (this=0x1074afb70, tw=@0x100f5b4e0) at pt-except.cc:99
#21 0x000000010067a16b in tree_evaluator::visit_statement (this=0x100f5b4e0, stmt=@0x1074afaf0) at pt-eval.cc:706
#22 0x00000001006a0fd1 in tree_statement::accept (this=0x1074afaf0, tw=@0x100f5b4e0) at pt-stmt.cc:151
#23 0x000000010067a572 in tree_evaluator::visit_statement_list (this=0x100f5b4e0, lst=@0x1074c51f0) at pt-eval.cc:772
#24 0x00000001006a1321 in tree_statement_list::accept (this=0x1074c51f0, tw=@0x100f5b4e0) at pt-stmt.cc:215
#25 0x00000001005ba0c1 in octave_user_function::do_multi_index_op (this=0x1074afc60, nargout=0, args=@0x1074c2f90, lvalue_list=0x0) at ov-usr-fcn.cc:475
#26 0x00000001005b9736 in octave_user_function::subsref (this=0x1074afc60, type=@0x7fff5fbfcf90, idx=@0x7fff5fbfd178, nargout=0, lvalue_list=0x0) at ov-usr-fcn.cc:327
#27 0x00000001005b955e in octave_user_function::subsref (this=0x1074afc60, type=@0x7fff5fbfcf90, idx=@0x7fff5fbfd178, nargout=0) at ov-usr-fcn.cc:310
#28 0x00000001005c6239 in octave_value::subsref (this=0x7fff5fbfd190, type=@0x7fff5fbfcf90, idx=@0x7fff5fbfd178, nargout=0) at ov.cc:1203
#29 0x00000001005c6315 in octave_value::subsref (this=0x7fff5fbfd190, type=@0x7fff5fbfcf90, idx=@0x7fff5fbfd178, nargout=0, lvalue_list=0x0) at ov.cc:1214
#30 0x0000000100681d95 in tree_index_expression::rvalue (this=0x1074940f0, nargout=0, lvalue_list=0x0) at pt-idx.cc:413
#31 0x0000000100680e5c in tree_index_expression::rvalue (this=0x1074940f0, nargout=0) at pt-idx.cc:284
#32 0x0000000100682160 in tree_index_expression::rvalue1 (this=0x1074940f0, nargout=0) at pt-idx.cc:425
#33 0x000000010067a313 in tree_evaluator::visit_statement (this=0x100f5b4e0, stmt=@0x1074c2ee0) at pt-eval.cc:736
#34 0x00000001006a0fd1 in tree_statement::accept (this=0x1074c2ee0, tw=@0x100f5b4e0) at pt-stmt.cc:151
#35 0x000000010067a572 in tree_evaluator::visit_statement_list (this=0x100f5b4e0, lst=@0x1074c2f00) at pt-eval.cc:772
#36 0x00000001006a1321 in tree_statement_list::accept (this=0x1074c2f00, tw=@0x100f5b4e0) at pt-stmt.cc:215
#37 0x000000010047c62e in main_loop () at toplev.cc:595
#38 0x000000010041629c in octave_main (argc=6, argv=0x7fff5fbfd958, embedded=0) at octave.cc:943
#39 0x0000000100000f47 in main (argc=6, argv=0x7fff5fbfd958) at main.c:35

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 06:29:38 PM UTC, comment #19:

Never mind the run-octave result--that's from not having the image in the right place.

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 06:15:41 PM UTC, comment #18:

I'm not a compiler expert, so "of course" is kind of Sergei-like to me. :-)

All the *FLAGS get set at ./configure time, so we should be good there. I'll dash out another build with everything tweaked and see what happens.

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 06:06:41 PM UTC, comment #17:

> Do I need to do more than just put -MD in the CFLAGS and CXXFLAGS to get debugging information?


You need -g, of course. I don't know if you need a more specific flag on Mac OS X:

http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Debugging-Options.html#Debugging-Options

And you have to put those flags when calling configure, not make (I think we have some bug about how these are handled).

It shouldn't matter too much, but you should also add these debug options to FFLAGS, as described in the wiki link above.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 07 Feb 2013 06:02:08 PM UTC, comment #16:

I kept the build directory around for my build with no optimizations. Interestingly enough, when I use the "run-octave" script, I get different output:

octave:1> imfinfo ("test.jpeg")
warning: your version of GraphicsMagick limits images to 16 bits per pixel
execvp failed, errno = 2 (No such file or directory)
Magick: "html2ps" "-U" "-o" "/var/folders/31/rrfrp0yx6pv3662971cj4hgc0000gn/T/gmFpfMf0" "/var/tmp/oct-qq9SYa".
error: Magick++ exception: Magick: Delegate failed ("html2ps" -U -o "%o" "%i") reported by magick/delegate.c:802 (InvokeDelegate)
error: called from:
error: /sw/src/fink.build/octave-ref-3.6.3-3/octave-3.6.3/scripts/image/imfinfo.m at line 147, column 10

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 05:55:00 PM UTC, comment #15:

Sorry about that. I get really tired of FUD about Fink. Our default build process is essentially:

configure
make
make install
<cram installed stuff into a .deb archive>

with appropriate path settings and the like. There are no hardcoded striplings of libraries or executables.

===

Do I need to do more than just put -MD in the CFLAGS and CXXFLAGS to get debugging information?

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 05:44:30 PM UTC, comment #14:

No change without optimization turned on. Unfortunately no line numbers, either.

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 05:38:30 PM UTC, comment #13:

I didn't say you did any damn stripping, just saying that if there was, it probably wasn't done by Octave (and if it was, that's another bug report).

I still don't understand why the stack trace is so incomplete if you're compiling with -O0, however.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 07 Feb 2013 05:15:34 PM UTC, comment #12:

The optimization used was -O0, for what it's worth. I'm trying a build without that.

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 05:11:58 PM UTC, comment #11:

No, I don't do any damn stripping. I do "make install" into a directory.

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 05:08:50 PM UTC, comment #10:

Octave's build files shouldn't strip, so if there is stripping involved, it's probably in the Fink packaging.

Can you compile without optimisations and without stripping and try again?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 07 Feb 2013 05:04:47 PM UTC, comment #9:

Yeah, I had optimizations turned on in the build.

This is technically from a production build, so if any stripping happens that's probably under what "make install".

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 04:56:41 PM UTC, comment #8:

Did you compile with optimisations or something? I would expect line numbers in the stack trace instead of hex offsets. Do you see anything obviously wrong in the function it's pointing to?

http://hg.savannah.gnu.org/hgweb/octave/file/ba304d49d2b2/libinterp/dldfcn/__magick_read__.cc#l1008

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 07 Feb 2013 04:56:15 PM UTC, comment #7:

That stack trace doesn't show any argument names/values or line numbers, which are things I would expect if your binary had debugging symbols. If you compiled with debugging symbols, were they somehow stripped from the copy you are running?

John W. Eaton <jwe>
Project Administrator
Thu 07 Feb 2013 04:46:06 PM UTC, comment #6:

I already had Octave set up to build with debug symbols, so a stack trace is easy enough:

octave:1> imfinfo("test.jpg")
Reading symbols for shared libraries ...
... done
warning: your version of GraphicsMagick limits images to 16 bits per pixel
Reading symbols for shared libraries .
. done
octave(79663,0x7fff7087fcc0) malloc: *** error for object 0x7fff70a0c500: pointer being freed was not allocated

      • set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
0x00007fff8588d0b6 in __kill ()
(gdb) bt
#0 0x00007fff8588d0b6 in __kill ()
#1 0x00007fff8592d9f6 in abort ()
#2 0x00007fff85845195 in free ()
#3 0x0000000104a063da in F__magick_finfo__ ()
#4 0x0000000100427b29 in octave_builtin::do_multi_index_op ()
#5 0x0000000100427e5d in octave_builtin::subsref ()
#6 0x0000000100428068 in octave_builtin::subsref ()
#7 0x0000000100428795 in octave_builtin::subsref ()
#8 0x00000001004c9a62 in octave_value::subsref ()
#9 0x00000001004c9b55 in octave_value::subsref ()
#10 0x000000010055e6fc in tree_index_expression::rvalue ()
#11 0x000000010055e89b in tree_index_expression::rvalue ()
#12 0x000000010055ccb1 in tree_index_expression::rvalue1 ()
#13 0x000000010054e444 in tree_simple_assignment::rvalue1 ()
#14 0x0000000100557c0d in tree_evaluator::visit_statement ()
#15 0x0000000100574560 in tree_statement::accept ()
#16 0x00000001005579b4 in tree_evaluator::visit_statement_list ()
#17 0x0000000100096826 in tree_statement_list::accept ()
#18 0x0000000100557649 in tree_evaluator::visit_unwind_protect_command ()
#19 0x00000001005596d0 in tree_unwind_protect_command::accept ()
#20 0x0000000100557b01 in tree_evaluator::visit_statement ()
#21 0x0000000100574560 in tree_statement::accept ()
#22 0x00000001005579b4 in tree_evaluator::visit_statement_list ()
#23 0x0000000100096826 in tree_statement_list::accept ()
#24 0x00000001004c3c96 in octave_user_function::do_multi_index_op ()
#25 0x00000001004c343d in octave_user_function::subsref ()
#26 0x00000001004c3648 in octave_user_function::subsref ()
#27 0x00000001004c9ac6 in octave_value::subsref ()
#28 0x00000001004c9b55 in octave_value::subsref ()
#29 0x000000010055e6fc in tree_index_expression::rvalue ()
#30 0x000000010055e89b in tree_index_expression::rvalue ()
#31 0x000000010055ccb1 in tree_index_expression::rvalue1 ()
#32 0x0000000100557c0d in tree_evaluator::visit_statement ()
#33 0x0000000100574560 in tree_statement::accept ()
#34 0x00000001005579b4 in tree_evaluator::visit_statement_list ()
#35 0x0000000100096826 in tree_statement_list::accept ()
#36 0x00000001003d0328 in main_loop ()
#37 0x00000001003880d0 in octave_main ()
#38 0x0000000100000f14 in start ()

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 04:40:46 PM UTC, comment #5:

For the specific case I'm referencing, gcc is gcc:

$ gcc --version | head -n2
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.

$ g++ --version | head -n2
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.

I get the same results even if I use gcc-4.7.2 to build Octave.

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 04:16:09 PM UTC, comment #4:

Furthermore, can you produce a stack trace?

http://wiki.octave.org/Debugging_Octave#Producing_a_stack_trace

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 07 Feb 2013 04:15:00 PM UTC, comment #3:

Is that actually gcc? Apple doesn't ship gcc, just a shim gcc interface to llvm. Can you try with an actual gcc?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 07 Feb 2013 02:13:50 AM UTC, comment #2:

The case I flagged is specifically on OS 10.6, and using Apple's gcc-4.2.1 compiler, because that's where we have both a 32-bit and a 64-bit option in Fink.

'32-bit' vs. '64-bit' refers to how the libraries/executables are built, along with all dependencies which aren't included with the operating system. There is NO mixing of 32-bit and 64-bit libraries. It's set via applying the "-arch i386" flag (which is an Apple-specific thing) to every build in the 64-bit setup, and applying the "-arch x86_64" flag to every build in the 32-bit setup.

Changing the compiler doesn't change the results, in any case.

Alexander Hansen <alexkhansen>
Thu 07 Feb 2013 01:54:28 AM UTC, comment #1:

What do you mean by "64-bit" vs. "32-bit" builds? Different compiler options? If so, which ones? What compiler? What version? Are you linking to a version of GraphicsMagick that was compiled the same way, or are you mixing 32-bit and 64-bit code? If so, then I don't see how this is a bug in Octave.

John W. Eaton <jwe>
Project Administrator
Thu 07 Feb 2013 12:51:59 AM UTC, original submission:

This occurs for Octave 3.4.3-3.6.3, on any OS X 10.5-10.8.

When I build Octave as 32-bit, the imfinfo() function works:

octave:1> imfinfo("test.jpg")
warning: your version of GraphicsMagick limits images to 16 bits per pixel
octave(77013,0xa02aa540) malloc: *** error for object 0xa0177db0: pointer being freed was not allocated

      • set a breakpoint in malloc_error_break to debug

octave(77013,0xa02aa540) malloc: *** error for object 0xa0177db0: pointer being freed was not allocated

      • set a breakpoint in malloc_error_break to debug

ans =

scalar structure containing the fields:

Filename = /Users/hansen/test.jpg
FileModDate = 5-Feb-2013 21:01:27
FileSize = 26699
Height = 241
Width = 241
BitDepth = 8
Format = JPEG
LongFormat = Joint Photographic Experts Group JFIF format
XResolution = 0
YResolution = 0
TotalColors = 68
TileName =
AnimationDelay = 0
AnimationIterations = 0
ByteOrder = undefined
Gamma = 0
Matte = 0
ModulusDepth = 8
Quality = 75
QuantizeColors = 256
ResolutionUnits = undefined
ColorType = grayscale
View =

When built as 64-bit, however, I get the following:

octave:1> imfinfo("test.jpg")
warning: your version of GraphicsMagick limits images to 16 bits per pixel
octave(77044,0x7fff7087fcc0) malloc: *** error for object 0x7fff70a0c500: pointer being freed was not allocated

      • set a breakpoint in malloc_error_break to debug

panic: Abort trap -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Abort trap

The 32-bit and 64-bit builds referenced above happen to be on the same machine, with analogous dependencies and using the same configure-time flags.

Anonymous

 

(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 jordigh (Posted a comment)
  • -unavailable- added by alexkhansen (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by None (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 project members can vote.

     

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

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 07 Feb 2013 04:16:09 PM UTCjordighStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup