GNU bug report logs - #24063
25.1; Emacs 25.1 RC1 crashes on Solaris 11.3 when asked to open and display an image

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24063 in the body.
You can then email your comments to 24063 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Henry Unger <hunger <at> hitech.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1;
 Emacs 25.1 RC1 crashes on Solaris 11.3 when asked to open and display
 an image
Date: Sun, 24 Jul 2016 14:29:49 -0700

From Dired, open any graphic file.


From dbx:

dbx) where
current thread: t <at> 1
=>[1] __lwp_sigqueue(0x0, 0x1, 0xb, 0x0, 0xffffffff, 0x0, 0xb, 0x6105b88), at 0x610cf85
  [2] thr_kill(0x1, 0xb, 0x8511298, 0x60af2e1), at 0x6105bb2
  [3] raise(0xb, 0x85112b0, 0x0, 0x0, 0x400, 0x0), at 0x60af2ed
  [4] terminate_due_to_signal(0xb, 0x28, 0x0, 0x1, 0x614ecc0, 0x614a000), at 0x81d6be5
  [5] deliver_fatal_signal(0x0, 0x1, 0xb, 0x0, 0xffffffff, 0x0), at 0x81f6f65
  [6] deliver_thread_signal(0xb, 0x81f6f4c, 0xfeffe78f, 0x405a, 0x614ecc0, 0x0), at 0x81f6f3c
  [7] deliver_fatal_thread_signal(0xb, 0x1, 0x614e5c0, 0x1, 0x0, 0x0, 0x0, 0xdf41c, 0x60df41c), at 0x81f6f99
  [8] handle_sigsegv(0xb, 0x851199c, 0x851144c, 0x60df3f7, 0xb, 0x614a000), at 0x81f7100
  [9] __sighndlr(0xb, 0x851199c, 0x851144c, 0x81f708c), at 0x61084b5
  [10] call_user_handler(0xb), at 0x60fb10e
  [11] sigacthandler(0xb, 0x851199c, 0x851144c, 0x1f, 0x0, 0x0), at 0x60fb5a6
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [12] imagemagick_load_image(0x8a0a100, 0x8b06a40, 0x0, 0x0, 0x8cc2fec, 0xe70), at 0x82e3f06
  [13] imagemagick_load(0x8a0a100, 0x8b06a40, 0x1e14050, 0xe70, 0x89eb955, 0x0), at 0x82e4130
  [14] lookup_image(0x8a0a100, 0x8952aab, 0xfeffb778, 0x81d45e5, 0x84da5e0, 0xa), at 0x82daccd
  [15] Fimage_size(0x8952aab, 0x55b0, 0x0, 0x82628cf, 0x8990c08, 0x2268), at 0x82d9741
  [16] Ffuncall(0x4, 0xfeffb840, 0xf, 0xfeffb838, 0x81d4488, 0x8952aab), at 0x8262561
  [17] exec_byte_code(0x8c1859c, 0x89eb955, 0x26, 0xc06, 0x2, 0xfeffbb80), at 0x829bd59
  [18] funcall_lambda(0x89d0685, 0x2, 0xfeffbb78, 0x0, 0x5, 0xfeffbed0), at 0x8262d03
  [19] Ffuncall(0x3, 0xfeffbb74, 0xfeffbb88, 0x81d4a9a, 0x1e, 0x6ce118), at 0x826278d
  [20] exec_byte_code(0x8640cd4, 0x8657195, 0x1e, 0x2, 0x0, 0xfeffbec8), at 0x829bd59
  [21] funcall_lambda(0x86571dd, 0x0, 0xfeffbec8, 0x81d409b, 0x3, 0x0), at 0x8262d03
  [22] Ffuncall(0x1, 0xfeffbec4, 0x0, 0x0, 0x89d0c55, 0x8a92acc), at 0x826278d
  [23] exec_byte_code(0x8bf01ac, 0x8a98c7d, 0x3e, 0x2, 0x0, 0xfeffc1f8), at 0x829bd59
  [24] funcall_lambda(0x8a98d65, 0x0, 0xfeffc1f8, 0x81d409b, 0x87c919d, 0x7), at 0x8262d03
  [25] Ffuncall(0x1, 0xfeffc1f4, 0x0, 0x0, 0x0, 0x6dc7a0), at 0x826278d
  [26] exec_byte_code(0x8bfd054, 0x8a9898d, 0x36, 0x2, 0x0, 0xfeffc550), at 0x829bd59
  [27] funcall_lambda(0x8a98a75, 0x0, 0xfeffc550, 0x0, 0x0, 0x2c), at 0x8262d03
  [28] Ffuncall(0x1, 0xfeffc54c, 0xfeffc558, 0x81d4a9a, 0x16, 0x27ac58), at 0x826278d
  [29] exec_byte_code(0x8351fcc, 0x8351fdd, 0x16, 0x806, 0x2, 0xfeffc8a0), at 0x829bd59
  [30] funcall_lambda(0x8351fb5, 0x2, 0xfeffc898, 0x82484fc, 0x8533c60, 0x48), at 0x8262d03
  [31] Ffuncall(0x3, 0xfeffc894, 0x8351dcd, 0x832bc95, 0x88bf793, 0x0), at 0x826278d
  [32] exec_byte_code(0x8351dbc, 0x8351dcd, 0x32, 0x402, 0x0, 0xfeffcbcc), at 0x829bd59
  [33] funcall_lambda(0x8351da5, 0x0, 0xfeffcbcc, 0x8649fa6, 0x2f, 0x2), at 0x8262d03
  [34] Ffuncall(0x1, 0xfeffcbc8, 0xfeffcbd8, 0x81d4a9a, 0x16, 0x55b0), at 0x826278d
  [35] exec_byte_code(0x83509f4, 0x8350a05, 0x16, 0x402, 0x1, 0xfeffcf10), at 0x829bd59
  [36] funcall_lambda(0x83509d5, 0x1, 0xfeffcf0c, 0x8247184, 0x8646e18, 0x8), at 0x8262d03
  [37] Ffuncall(0x2, 0xfeffcf08, 0x0, 0x0, 0x81d4488, 0x0), at 0x826278d
  [38] exec_byte_code(0x8350814, 0x8350825, 0x2a, 0x1402, 0x2, 0xfeffd25c), at 0x829bd59
  [39] funcall_lambda(0x83507fd, 0x2, 0xfeffd254, 0x8247184, 0x8646e18, 0x8), at 0x8262d03
  [40] Ffuncall(0x3, 0xfeffd250, 0x0, 0x0, 0x81d4488, 0x8646e1d), at 0x826278d
  [41] exec_byte_code(0x835047c, 0x835048d, 0x2e, 0x181a, 0x6, 0xfeffd5b4), at 0x829bd59
  [42] funcall_lambda(0x8350465, 0x6, 0xfeffd59c, 0x2f, 0x2f, 0x2), at 0x8262d03
  [43] Ffuncall(0x7, 0xfeffd598, 0x2f, 0x0, 0xfeffd58c, 0x8592894), at 0x826278d
  [44] exec_byte_code(0x83501d4, 0x83501e5, 0x46, 0x1006, 0x4, 0xfeffd8f0), at 0x829bd59
  [45] funcall_lambda(0x83501bd, 0x4, 0xfeffd8e0, 0x7472784, 0x8908f30, 0x1000000), at 0x8262d03
  [46] Ffuncall(0x5, 0xfeffd8dc, 0xfeffd8e8, 0x81d4a9a, 0x1e, 0x8592964), at 0x826278d
  [47] exec_byte_code(0x834f464, 0x834f475, 0x1e, 0x806, 0x1, 0xfeffdc0c), at 0x829bd59
  [48] funcall_lambda(0x834f445, 0x1, 0xfeffdc08, 0x8247ff5, 0x8709c40, 0x221578), at 0x8262d03
  [49] Ffuncall(0x2, 0xfeffdc04, 0xfeffdc28, 0xfeffdc08, 0x81d3b03, 0x216cc0), at 0x826278d
  [50] exec_byte_code(0x8c1f38c, 0x8c19655, 0xa, 0x2, 0x0, 0xfeffe074), at 0x829bd59
  [51] funcall_lambda(0x8c1966d, 0x0, 0xfeffe074, 0xfeffde98, 0x81d3930, 0x3708), at 0x8262d03
  [52] Ffuncall(0x1, 0xfeffe070, 0xfeffdf38, 0x81d5086, 0x0, 0x84d7c38), at 0x826278d
  [53] Ffuncall_interactively(0x1, 0xfeffe070, 0x1, 0x85233f0, 0x81d3930, 0x3708), at 0x825b725
  [54] Ffuncall(0x2, 0xfeffe06c, 0x0, 0x1, 0x3660, 0x88b71d3), at 0x8262429
  [55] Fapply(0x3, 0xfeffe06c, 0x0, 0xfeffe048, 0x81d3930, 0x851fce8), at 0x82616f8
  [56] Fcall_interactively(0x6b7498, 0x0, 0x8538b7d, 0x8247161, 0x8514bf0, 0x8a6d5b0), at 0x825bab3
  [57] Ffuncall(0x4, 0xfeffe1fc, 0x0, 0x0, 0x1, 0x6b7498), at 0x8262561
  [58] exec_byte_code(0x838b724, 0x838b735, 0x36, 0x1006, 0x1, 0xfeffe540), at 0x829bd59
  [59] funcall_lambda(0x838b70d, 0x1, 0xfeffe53c, 0x82628cf, 0x8990ab8, 0x0), at 0x8262d03
  [60] Ffuncall(0x2, 0xfeffe538, 0xfeffe548, 0x8262043, 0x1, 0xfeffe550), at 0x826278d
  [61] call1(0x1cc8, 0x6b7498, 0x88b7223, 0x0, 0x1, 0x1), at 0x826206a
  [62] command_loop_1(0x8a73224, 0x1, 0xe9ceab0, 0x8a731a8, 0x8067c9c, 0x8534f2b), at 0x81db24d
  [63] internal_condition_case(0x81daae9, 0x24f0, 0x81da31b, 0x8a731a8, 0xfeffe698, 0x0), at 0x825f897
  [64] command_loop_2(0x0, 0x0, 0xfe78004b, 0xfeffe8a0, 0xfeffe7d0, 0xfeffe6c8), at 0x81da80b
  [65] internal_catch(0x5868, 0x81da7e0, 0x0, 0x1, 0x80b81be, 0xe), at 0x825f2e4
  [66] command_loop(0x5be0, 0x0, 0xfeffe8a0, 0x823db77, 0x8a730f0, 0x0), at 0x81da7a5
  [67] recursive_edit_1(0x81da109, 0x0, 0xfeffe728, 0x827d5fe, 0x392, 0x853ff3d), at 0x81d9f7a
  [68] Frecursive_edit(0x0, 0x0, 0x1, 0x0, 0x2, 0x0), at 0x81da0ec
  [69] main(0x1, 0xfeffe814, 0xfeffe81c, 0xfeffe808, 0x80c74b2, 0x8307740), at 0x81d83b9

The version of imagemagick is that installed from Oracle's Solaris
package repository:

$ convert --version
Version: ImageMagick 6.9.4-2 Q16 i386 2016-06-01 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2016 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC Modules
Delegates (built-in): bzlib fftw freetype jng jpeg ltdl lzma openexr pangocairo png tiff x xml

$ pkg info imagemagick
             Name: image/imagemagick
          Summary: ImageMagick - Image Manipulation Utilities and Libraries
      Description: ImageMagick is a software suite to create, edit, compose, or
                   convert images
         Category: System/Multimedia Libraries
            State: Installed
        Publisher: solaris
          Version: 6.9.4.2 (6.9.4-2)
    Build Release: 5.11
           Branch: 0.175.3.9.0.3.0
   Packaging Date: Wed Jun 08 19:59:34 2016
             Size: 33.19 MB
             FMRI: pkg://solaris/image/imagemagick <at> 6.9.4.2,5.11-0.175.3.9.0.3.0:20160608T195934Z

In GNU Emacs 25.1.1 (i386-pc-solaris2.11, GTK+ Version 2.20.1)
 of 2016-07-24 built on sol11vm.cody.hitech.com
Windowing system distributor 'StarNet Communications Corp.', version 11.0.14000
Configured using:
 'configure CFLAGS=-I/opt/csw/include'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK DBUS GCONF GSETTINGS NOTIFY ACL
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11

Important settings:
  value of $LC_ALL: 
  value of $LC_COLLATE: 
  value of $LC_CTYPE: 
  value of $LC_MESSAGES: 
  value of $LC_MONETARY: 
  value of $LC_NUMERIC: 
  value of $LC_TIME: 
  locale-coding-system: nil

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-_ C-a.
current-kill: Kill ring is empty

Load-path shadows:
None found.

Features:
(shadow sort mail-extr warnings emacsbug message dired format-spec
rfc822 mml mml-sec password-cache epg epg-config gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind gfilenotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 8 90897 7868)
 (symbols 24 19847 0)
 (miscs 20 93 186)
 (strings 16 14665 4109)
 (string-bytes 1 417175)
 (vectors 8 12495)
 (vector-slots 4 447015 6158)
 (floats 8 173 29)
 (intervals 28 255 223)
 (buffers 520 21))

Message #8 received at 24063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Henry Unger <hunger <at> hitech.com>
Cc: 24063 <at> debbugs.gnu.org
Subject: Re: bug#24063: 25.1;
 Emacs 25.1 RC1 crashes on Solaris 11.3 when asked to open and display
 an image
Date: Mon, 25 Jul 2016 05:32:11 +0300

> From: Henry Unger <hunger <at> hitech.com>
> Date: Sun, 24 Jul 2016 14:29:49 -0700
> 
> 
> >From Dired, open any graphic file.
> 
> 
> >From dbx:
> 
> dbx) where
> current thread: t <at> 1
> =>[1] __lwp_sigqueue(0x0, 0x1, 0xb, 0x0, 0xffffffff, 0x0, 0xb, 0x6105b88), at 0x610cf85
>   [2] thr_kill(0x1, 0xb, 0x8511298, 0x60af2e1), at 0x6105bb2
>   [3] raise(0xb, 0x85112b0, 0x0, 0x0, 0x400, 0x0), at 0x60af2ed
>   [4] terminate_due_to_signal(0xb, 0x28, 0x0, 0x1, 0x614ecc0, 0x614a000), at 0x81d6be5
>   [5] deliver_fatal_signal(0x0, 0x1, 0xb, 0x0, 0xffffffff, 0x0), at 0x81f6f65
>   [6] deliver_thread_signal(0xb, 0x81f6f4c, 0xfeffe78f, 0x405a, 0x614ecc0, 0x0), at 0x81f6f3c
>   [7] deliver_fatal_thread_signal(0xb, 0x1, 0x614e5c0, 0x1, 0x0, 0x0, 0x0, 0xdf41c, 0x60df41c), at 0x81f6f99
>   [8] handle_sigsegv(0xb, 0x851199c, 0x851144c, 0x60df3f7, 0xb, 0x614a000), at 0x81f7100
>   [9] __sighndlr(0xb, 0x851199c, 0x851144c, 0x81f708c), at 0x61084b5
>   [10] call_user_handler(0xb), at 0x60fb10e
>   [11] sigacthandler(0xb, 0x851199c, 0x851144c, 0x1f, 0x0, 0x0), at 0x60fb5a6
>   ---- called from signal handler with signal 11 (SIGSEGV) ------
>   [12] imagemagick_load_image(0x8a0a100, 0x8b06a40, 0x0, 0x0, 0x8cc2fec, 0xe70), at 0x82e3f06
>   [13] imagemagick_load(0x8a0a100, 0x8b06a40, 0x1e14050, 0xe70, 0x89eb955, 0x0), at 0x82e4130

Thanks.  Can you add source line numbers to the backtrace?

Also, did you try any of the pretests, and if so, did they work
correctly in these cases?

Message #11 received at 24063 <at> debbugs.gnu.org (full text, mbox):

From: Henry Unger <hunger <at> hitech.com>
To: 'Eli Zaretskii' <eliz <at> gnu.org>
Cc: 24063 <at> debbugs.gnu.org
Subject: RE: bug#24063: 25.1;
 Emacs 25.1 RC1 crashes on Solaris 11.3 when asked to open and display
 an image
Date: Mon, 25 Jul 2016 00:00:06 -0700

> From: Eli Zaretskii [mailto:eliz <at> gnu.org]
> Sent: Sunday, July 24, 2016 7:32 PM
> To: Henry Unger <hunger <at> hitech.com>
> Cc: 24063 <at> debbugs.gnu.org
> Subject: Re: bug#24063: 25.1; Emacs 25.1 RC1 crashes on Solaris 11.3 when
> asked to open and display an image
> 
> > From: Henry Unger <hunger <at> hitech.com>
> > Date: Sun, 24 Jul 2016 14:29:49 -0700
> >
> > >From Dired, open any graphic file.
> >
> >
> > >From dbx:
> >
> > dbx) where
> > current thread: t <at> 1
> > =>[1] __lwp_sigqueue(0x0, 0x1, 0xb, 0x0, 0xffffffff, 0x0, 0xb, 0x6105b88),
> at 0x610cf85
> >   [2] thr_kill(0x1, 0xb, 0x8511298, 0x60af2e1), at 0x6105bb2
> >   [3] raise(0xb, 0x85112b0, 0x0, 0x0, 0x400, 0x0), at 0x60af2ed
> >   [4] terminate_due_to_signal(0xb, 0x28, 0x0, 0x1, 0x614ecc0, 0x614a000),
> at 0x81d6be5
> >   [5] deliver_fatal_signal(0x0, 0x1, 0xb, 0x0, 0xffffffff, 0x0), at 0x81f6f65
> >   [6] deliver_thread_signal(0xb, 0x81f6f4c, 0xfeffe78f, 0x405a, 0x614ecc0,
> 0x0), at 0x81f6f3c
> >   [7] deliver_fatal_thread_signal(0xb, 0x1, 0x614e5c0, 0x1, 0x0, 0x0, 0x0,
> 0xdf41c, 0x60df41c), at 0x81f6f99
> >   [8] handle_sigsegv(0xb, 0x851199c, 0x851144c, 0x60df3f7, 0xb,
> 0x614a000), at 0x81f7100
> >   [9] __sighndlr(0xb, 0x851199c, 0x851144c, 0x81f708c), at 0x61084b5
> >   [10] call_user_handler(0xb), at 0x60fb10e
> >   [11] sigacthandler(0xb, 0x851199c, 0x851144c, 0x1f, 0x0, 0x0), at 0x60fb5a6
> >   ---- called from signal handler with signal 11 (SIGSEGV) ------
> >   [12] imagemagick_load_image(0x8a0a100, 0x8b06a40, 0x0, 0x0, 0x8cc2fec,
> 0xe70), at 0x82e3f06
> >   [13] imagemagick_load(0x8a0a100, 0x8b06a40, 0x1e14050, 0xe70,
> > 0x89eb955, 0x0), at 0x82e4130
> 
> Thanks.  Can you add source line numbers to the backtrace?

I rebuilt it, adding "-g" to CFLAGS, and  reproduced the problem, which now shows line numbers:

current thread: t <at> 1
  [1] __lwp_sigqueue(0x0, 0x1, 0xb, 0x0, 0xffffffff, 0x0, 0xb, 0x6105b88), at 0x610cf85
  [2] thr_kill(0x1, 0xb, 0x8511298, 0x60af2e1), at 0x6105bb2
  [3] raise(0xb, 0x85112b0, 0x0, 0x0, 0x400, 0x0), at 0x60af2ed
=>[4] terminate_due_to_signal(sig = 11, backtrace_limit = 40), line 381 in "emacs.c"
  [5] deliver_fatal_signal(sig = <bad address 0x00000004>), line 1607 in "sysdep.c"
  [6] deliver_thread_signal(sig = 11, handler = 0x81f6f4c = &`emacs`sysdep.c`handle_fatal_signal(int sig)), line 1575 in "sysdep.c"
  [7] deliver_fatal_thread_signal(sig = 11), line 1613 in "sysdep.c"
  [8] handle_sigsegv(sig = 11, siginfo = 0x851199c, arg = 0x851144c), line 1695 in "sysdep.c"
  [9] __sighndlr(0xb, 0x851199c, 0x851144c, 0x81f708c), at 0x61084b5
  [10] call_user_handler(0xb), at 0x60fb10e
  [11] sigacthandler(0xb, 0x851199c, 0x851144c, 0x1f, 0x0, 0x0), at 0x60fb5a6
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [12] imagemagick_load_image(f = 0x8a0c5a8, img = 0x8afcd00, contents = (nil), size = 0, filename = 0x8caa450 "/home/hunger/foo.png"), line 8787 in "image.c"
  [13] imagemagick_load(f = 0x8a0c5a8, img = 0x8afcd00), line 8853 in "image.c"
  [14] lookup_image(f = 0x8a0c5a8, spec = 147473323), line 1746 in "image.c"
  [15] Fimage_size(spec = 147473323, pixels = 21936, frame = 0), line 871 in "image.c"
  [16] Ffuncall(nargs = 4, args = 0xfeffb840), line 2700 in "eval.c"
  [17] exec_byte_code(bytestr = 139881620, vector = 145318029, maxdepth = 38, args_template = 3078, nargs = 2, args = 0xfeffbb80), line 880 in "bytecode.c"
  [18] funcall_lambda(fun = 145318093, nargs = 2, arg_vector = (nil)), line 2855 in "eval.c"
  [19] Ffuncall(nargs = 3, args = 0xfeffbb74), line 2742 in "eval.c"
  [20] exec_byte_code(bytestr = 147183476, vector = 147179237, maxdepth = 30, args_template = 2, nargs = 0, args = 0xfeffbec8), line 880 in "bytecode.c"
  [21] funcall_lambda(fun = 147179309, nargs = 0, arg_vector = (nil)), line 2855 in "eval.c"
  [22] Ffuncall(nargs = 1, args = 0xfeffbec4), line 2742 in "eval.c"
  [23] exec_byte_code(bytestr = 146751148, vector = 147177733, maxdepth = 62, args_template = 2, nargs = 0, args = 0xfeffc1f8), line 880 in "bytecode.c"
  [24] funcall_lambda(fun = 140606525, nargs = 0, arg_vector = (nil)), line 2855 in "eval.c"
  [25] Ffuncall(nargs = 1, args = 0xfeffc1f4), line 2742 in "eval.c"
  [26] exec_byte_code(bytestr = 146816956, vector = 140605773, maxdepth = 54, args_template = 2, nargs = 0, args = 0xfeffc550), line 880 in "bytecode.c"
  [27] funcall_lambda(fun = 140606005, nargs = 0, arg_vector = (nil)), line 2855 in "eval.c"
  [28] Ffuncall(nargs = 1, args = 0xfeffc54c), line 2742 in "eval.c"
  [29] exec_byte_code(bytestr = 137699276, vector = 137699293, maxdepth = 22, args_template = 2054, nargs = 2, args = 0xfeffc8a0), line 880 in "bytecode.c"
  [30] funcall_lambda(fun = 137699253, nargs = 2, arg_vector = (nil)), line 2855 in "eval.c"
  [31] Ffuncall(nargs = 3, args = 0xfeffc894), line 2742 in "eval.c"
  [32] exec_byte_code(bytestr = 137698748, vector = 137698765, maxdepth = 50, args_template = 1026, nargs = 0, args = 0xfeffcbcc), line 880 in "bytecode.c"
  [33] funcall_lambda(fun = 137698725, nargs = 0, arg_vector = (nil)), line 2855 in "eval.c"
  [34] Ffuncall(nargs = 1, args = 0xfeffcbc8), line 2742 in "eval.c"
  [35] exec_byte_code(bytestr = 137693684, vector = 137693701, maxdepth = 22, args_template = 1026, nargs = 1, args = 0xfeffcf10), line 880 in "bytecode.c"
  [36] funcall_lambda(fun = 137693653, nargs = 1, arg_vector = (nil)), line 2855 in "eval.c"
  [37] Ffuncall(nargs = 2, args = 0xfeffcf08), line 2742 in "eval.c"
  [38] exec_byte_code(bytestr = 137693204, vector = 137693221, maxdepth = 42, args_template = 5122, nargs = 2, args = 0xfeffd25c), line 880 in "bytecode.c"
  [39] funcall_lambda(fun = 137693181, nargs = 2, arg_vector = (nil)), line 2855 in "eval.c"
  [40] Ffuncall(nargs = 3, args = 0xfeffd250), line 2742 in "eval.c"
  [41] exec_byte_code(bytestr = 137692284, vector = 137692301, maxdepth = 46, args_template = 6170, nargs = 6, args = 0xfeffd5b4), line 880 in "bytecode.c"
  [42] funcall_lambda(fun = 137692261, nargs = 6, arg_vector = (nil)), line 2855 in "eval.c"
  [43] Ffuncall(nargs = 7, args = 0xfeffd598), line 2742 in "eval.c"
  [44] exec_byte_code(bytestr = 137691604, vector = 137691621, maxdepth = 70, args_template = 4102, nargs = 4, args = 0xfeffd8f0), line 880 in "bytecode.c"
  [45] funcall_lambda(fun = 137691581, nargs = 4, arg_vector = (nil)), line 2855 in "eval.c"
  [46] Ffuncall(nargs = 5, args = 0xfeffd8dc), line 2742 in "eval.c"
  [47] exec_byte_code(bytestr = 137688164, vector = 137688181, maxdepth = 30, args_template = 2054, nargs = 1, args = 0xfeffdc0c), line 880 in "bytecode.c"
  [48] funcall_lambda(fun = 137688133, nargs = 1, arg_vector = (nil)), line 2855 in "eval.c"
  [49] Ffuncall(nargs = 2, args = 0xfeffdc04), line 2742 in "eval.c"
  [50] exec_byte_code(bytestr = 145733324, vector = 141664597, maxdepth = 10, args_template = 2, nargs = 0, args = 0xfeffe074), line 880 in "bytecode.c"
  [51] funcall_lambda(fun = 142656525, nargs = 0, arg_vector = (nil)), line 2855 in "eval.c"
  [52] Ffuncall(nargs = 1, args = 0xfeffe070), line 2742 in "eval.c"
  [53] Ffuncall_interactively(nargs = 1, args = 0xfeffe070), line 252 in "callint.c"
  [54] Ffuncall(nargs = 2, args = 0xfeffe06c), line 2673 in "eval.c"
  [55] Fapply(nargs = 3, args = 0xfeffe06c), line 2274 in "eval.c"
  [56] Fcall_interactively(function = 6460208, record_flag = 0, keys = 139692925), line 389 in "callint.c"
  [57] Ffuncall(nargs = 4, args = 0xfeffe1fc), line 2700 in "eval.c"
  [58] exec_byte_code(bytestr = 137934628, vector = 137934645, maxdepth = 54, args_template = 4102, nargs = 1, args = 0xfeffe540), line 880 in "bytecode.c"
  [59] funcall_lambda(fun = 137934605, nargs = 1, arg_vector = (nil)), line 2855 in "eval.c"
  [60] Ffuncall(nargs = 2, args = 0xfeffe538), line 2742 in "eval.c"
  [61] call1(fn = 7368, arg1 = 6460208), line 2552 in "eval.c"
  [62] command_loop_1(), line 1479 in "keyboard.c"
  [63] internal_condition_case(bfun = 0x81daae9 = &command_loop_1(), handlers = 9456, hfun = 0x81da31b = &`emacs`keyboard.c`cmd_error(Lisp_Object data)), line 1309 in "eval.c"
  [64] command_loop_2(ignore = 0), line 1107 in "keyboard.c"
  [65] internal_catch(tag = 22632, func = 0x81da7e0 = &`emacs`keyboard.c`command_loop_2(Lisp_Object ignore), arg = 0), line 1074 in "eval.c"
  [66] command_loop(), line 1086 in "keyboard.c"
  [67] recursive_edit_1(), line 692 in "keyboard.c"
  [68] Frecursive_edit(), line 763 in "keyboard.c"
  [69] main(argc = 1, argv = 0xfeffe814), line 1626 in "emacs.c"

> 
> Also, did you try any of the pretests, and if so, did they work correctly in
> these cases?

I did try the pretests and the same problem was present in all of them. I'm sorry I did not report the problem sooner.

Emacs 24.3.1 does not crash running on the same system.

Message #14 received at 24063 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Henry Unger <hunger <at> hitech.com>, 'Eli Zaretskii' <eliz <at> gnu.org>
Cc: 24063 <at> debbugs.gnu.org
Subject: Re: bug#24063: 25.1;
 Emacs 25.1 RC1 crashes on Solaris 11.3 when asked to open and
 display	an image
Date: Mon, 25 Jul 2016 10:57:35 +0200

[Message part 1 (text/plain, inline)]

Henry Unger <hunger <at> hitech.com> writes:

> Emacs 24.3.1 does not crash running on the same system.

What about Emacs 24.5?

Cheers,
Nico

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 24063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Henry Unger <hunger <at> hitech.com>
Cc: 24063 <at> debbugs.gnu.org
Subject: Re: bug#24063: 25.1;
 Emacs 25.1 RC1 crashes on Solaris 11.3 when asked to open and display
 an image
Date: Mon, 25 Jul 2016 19:39:17 +0300

> Date: Mon, 25 Jul 2016 00:00:06 -0700
> From: Henry Unger <hunger <at> hitech.com>
> Cc: 24063 <at> debbugs.gnu.org
> 
> I rebuilt it, adding "-g" to CFLAGS, and  reproduced the problem, which now shows line numbers:
> 
> current thread: t <at> 1
>   [1] __lwp_sigqueue(0x0, 0x1, 0xb, 0x0, 0xffffffff, 0x0, 0xb, 0x6105b88), at 0x610cf85
>   [2] thr_kill(0x1, 0xb, 0x8511298, 0x60af2e1), at 0x6105bb2
>   [3] raise(0xb, 0x85112b0, 0x0, 0x0, 0x400, 0x0), at 0x60af2ed
> =>[4] terminate_due_to_signal(sig = 11, backtrace_limit = 40), line 381 in "emacs.c"
>   [5] deliver_fatal_signal(sig = <bad address 0x00000004>), line 1607 in "sysdep.c"
>   [6] deliver_thread_signal(sig = 11, handler = 0x81f6f4c = &`emacs`sysdep.c`handle_fatal_signal(int sig)), line 1575 in "sysdep.c"
>   [7] deliver_fatal_thread_signal(sig = 11), line 1613 in "sysdep.c"
>   [8] handle_sigsegv(sig = 11, siginfo = 0x851199c, arg = 0x851144c), line 1695 in "sysdep.c"
>   [9] __sighndlr(0xb, 0x851199c, 0x851144c, 0x81f708c), at 0x61084b5
>   [10] call_user_handler(0xb), at 0x60fb10e
>   [11] sigacthandler(0xb, 0x851199c, 0x851144c, 0x1f, 0x0, 0x0), at 0x60fb5a6
>   ---- called from signal handler with signal 11 (SIGSEGV) ------
>   [12] imagemagick_load_image(f = 0x8a0c5a8, img = 0x8afcd00, contents = (nil), size = 0, filename = 0x8caa450 "/home/hunger/foo.png"), line 8787 in "image.c"

Thanks.  This is here:

	  int xlim = min (row_width, width);
	  for (x = 0; x < xlim; x++)
            {
              PixelGetMagickColor (pixels[x], &pixel);
              XPutPixel (ximg, x, y,  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
                         lookup_rgb_color (f,
					   color_scale * pixel.red,
					   color_scale * pixel.green,
					   color_scale * pixel.blue));
            }

That particular line is a strange place to crash.  Can you tell what
are the values of ximg, xlim, x, y, and pixels[x] when it crashes?

Message #20 received at 24063 <at> debbugs.gnu.org (full text, mbox):

From: Henry Unger <hunger <at> hitech.com>
To: 'Nicolas Petton' <nicolas <at> petton.fr>, 'Eli Zaretskii' <eliz <at> gnu.org>
Cc: 24063 <at> debbugs.gnu.org
Subject: RE: bug#24063: 25.1; Emacs 25.1 RC1 crashes on Solaris 11.3 when
 asked to open and display an image
Date: Tue, 26 Jul 2016 15:18:49 -0700

> -----Original Message-----
> From: Nicolas Petton [mailto:nicolas <at> petton.fr]
> Sent: Monday, July 25, 2016 1:58 AM
> To: Henry Unger <hunger <at> hitech.com>; 'Eli Zaretskii' <eliz <at> gnu.org>
> Cc: 24063 <at> debbugs.gnu.org
> Subject: Re: bug#24063: 25.1; Emacs 25.1 RC1 crashes on Solaris 11.3 when
> asked to open and display an image
> 
> Henry Unger <hunger <at> hitech.com> writes:
> 
> > Emacs 24.3.1 does not crash running on the same system.
> 
> What about Emacs 24.5?
> 
> Cheers,
> Nico

I installed 24.5 and it works fine for that version.

Best regards,

Henry

Message #23 received at 24063 <at> debbugs.gnu.org (full text, mbox):

From: Henry Unger <hunger <at> hitech.com>
To: 'Eli Zaretskii' <eliz <at> gnu.org>
Cc: 24063 <at> debbugs.gnu.org
Subject: RE: bug#24063: 25.1; Emacs 25.1 RC1 crashes on Solaris 11.3 when
 asked to open and display an image
Date: Tue, 26 Jul 2016 20:03:35 -0700

> -----Original Message-----
> From: Eli Zaretskii [mailto:eliz <at> gnu.org]
> Sent: Monday, July 25, 2016 9:39 AM
> To: Henry Unger <hunger <at> hitech.com>
> Cc: 24063 <at> debbugs.gnu.org
> Subject: Re: bug#24063: 25.1; Emacs 25.1 RC1 crashes on Solaris 11.3 when
> asked to open and display an image
> 
> > Date: Mon, 25 Jul 2016 00:00:06 -0700
> > From: Henry Unger <hunger <at> hitech.com>
> > Cc: 24063 <at> debbugs.gnu.org
> >
> > I rebuilt it, adding "-g" to CFLAGS, and  reproduced the problem, which now
> shows line numbers:
> >
> > current thread: t <at> 1
> >   [1] __lwp_sigqueue(0x0, 0x1, 0xb, 0x0, 0xffffffff, 0x0, 0xb, 0x6105b88), at
> 0x610cf85
> >   [2] thr_kill(0x1, 0xb, 0x8511298, 0x60af2e1), at 0x6105bb2
> >   [3] raise(0xb, 0x85112b0, 0x0, 0x0, 0x400, 0x0), at 0x60af2ed =>[4]
> > terminate_due_to_signal(sig = 11, backtrace_limit = 40), line 381 in
> "emacs.c"
> >   [5] deliver_fatal_signal(sig = <bad address 0x00000004>), line 1607 in
> "sysdep.c"
> >   [6] deliver_thread_signal(sig = 11, handler = 0x81f6f4c =
> &`emacs`sysdep.c`handle_fatal_signal(int sig)), line 1575 in "sysdep.c"
> >   [7] deliver_fatal_thread_signal(sig = 11), line 1613 in "sysdep.c"
> >   [8] handle_sigsegv(sig = 11, siginfo = 0x851199c, arg = 0x851144c), line 1695
> in "sysdep.c"
> >   [9] __sighndlr(0xb, 0x851199c, 0x851144c, 0x81f708c), at 0x61084b5
> >   [10] call_user_handler(0xb), at 0x60fb10e
> >   [11] sigacthandler(0xb, 0x851199c, 0x851144c, 0x1f, 0x0, 0x0), at 0x60fb5a6
> >   ---- called from signal handler with signal 11 (SIGSEGV) ------
> >   [12] imagemagick_load_image(f = 0x8a0c5a8, img = 0x8afcd00, contents =
> (nil), size = 0, filename = 0x8caa450 "/home/hunger/foo.png"), line 8787 in
> "image.c"
> 
> Thanks.  This is here:
> 
> 	  int xlim = min (row_width, width);
> 	  for (x = 0; x < xlim; x++)
>             {
>               PixelGetMagickColor (pixels[x], &pixel);
>               XPutPixel (ximg, x, y,  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>                          lookup_rgb_color (f,
> 					   color_scale * pixel.red,
> 					   color_scale * pixel.green,
> 					   color_scale * pixel.blue));
>             }
> 
> That particular line is a strange place to crash.  Can you tell what are the
> values of ximg, xlim, x, y, and pixels[x] when it crashes?

ximg = 0x400e
xlim = 0 
x = 0
y = 0
(dbx) print pixels[x]
dbx: cannot access address 0xffff0000

Henry

Message #26 received at 24063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Henry Unger <hunger <at> hitech.com>
Cc: 24063 <at> debbugs.gnu.org
Subject: Re: bug#24063: 25.1; Emacs 25.1 RC1 crashes on Solaris 11.3 when
 asked to open and display an image
Date: Wed, 27 Jul 2016 19:00:32 +0300

> Date: Tue, 26 Jul 2016 20:03:35 -0700
> From: Henry Unger <hunger <at> hitech.com>
> Cc: 24063 <at> debbugs.gnu.org
> 
> > 	  int xlim = min (row_width, width);
> > 	  for (x = 0; x < xlim; x++)
> >             {
> >               PixelGetMagickColor (pixels[x], &pixel);
> >               XPutPixel (ximg, x, y,  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >                          lookup_rgb_color (f,
> > 					   color_scale * pixel.red,
> > 					   color_scale * pixel.green,
> > 					   color_scale * pixel.blue));
> >             }
> > 
> > That particular line is a strange place to crash.  Can you tell what are the
> > values of ximg, xlim, x, y, and pixels[x] when it crashes?
> 
> ximg = 0x400e
> xlim = 0 
> x = 0
> y = 0
> (dbx) print pixels[x]
> dbx: cannot access address 0xffff0000

So the problem is in the value returned by PixelGetNextIteratorRow.
The only ideas I have is (a) upgrade to a later version of
ImageMagick, and (b) ask on some ImageMagick forum about similar
problems.

Thanks.

Message #29 received at 24063 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24063 <at> debbugs.gnu.org, Henry Unger <hunger <at> hitech.com>
Subject: Re: bug#24063: 25.1; Emacs 25.1 RC1 crashes on Solaris 11.3 when
 asked to open and display an image
Date: Thu, 26 Sep 2019 18:00:47 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> ximg = 0x400e
>> xlim = 0 
>> x = 0
>> y = 0
>> (dbx) print pixels[x]
>> dbx: cannot access address 0xffff0000
>
> So the problem is in the value returned by PixelGetNextIteratorRow.
> The only ideas I have is (a) upgrade to a later version of
> ImageMagick, and (b) ask on some ImageMagick forum about similar
> problems.

As this seems to be likely to be an ImageMagick bug (and Emacs doesn't
build with ImageMagick by default any more), I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.