* Crash when loading GIF images
@ 2013-12-31 8:18 Elias Mårtenson
2013-12-31 8:50 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Elias Mårtenson @ 2013-12-31 8:18 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 7708 bytes --]
Since at least several months, after compiling Emacs from source on Arch
Linux, the entire Emacs session crashes when displaying any GIF image. The
stack trace shows the crash happening inside giflib.
Forcing Emacs to build with libungif instead fixes the problem, so it has
something to do with how Emacs uses giflib.
Here's the stack trace from the crash in case anyone has any idea. I
haven't tried to analyse this in any depth myself yet.
Reproducing the error is very easy for me. All I have to do is to open any
GIF file and it immediately crashes.
The version of giflib in my release of Arch Linux is: 5.0.5
I can reproduce this error with the latest sync from the source repository
(I'm using the GIT mirror).
Regards,
Elias
Stack trace:
#0 gif_load (f=0x116b4d8, img=0x297ab50) at image.c:7454
#1 0x00000000005bea95 in lookup_image (f=f@entry=0x116b4d8,
spec=spec@entry=43558006) at image.c:1694
#2 0x00000000005beece in Fimage_metadata (spec=43558006, frame=12338034)
at image.c:945
#3 0x00000000005504ab in Ffuncall (nargs=<optimized out>,
args=<optimized out>) at eval.c:2808
#4 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=47, args=0x2) at
bytecode.c:919
#5 0x000000000054ff7f in funcall_lambda (fun=10238869, nargs=nargs@entry
=1,
arg_vector=arg_vector@entry=0x7fffffffcd88) at eval.c:3039
#6 0x00000000005502db in Ffuncall (nargs=2, args=0x7fffffffcd80)
at eval.c:2866
#7 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=140737488342392, args=0x2)
at bytecode.c:919
#8 0x0000000000550017 in funcall_lambda (fun=30384189, nargs=nargs@entry
=0,
arg_vector=0x7fffffffd120, arg_vector@entry=0x7fffffffcf28) at
eval.c:2973
#9 0x00000000005502db in Ffuncall (nargs=1, args=0x7fffffffcf20)
at eval.c:2866
#10 0x000000000054fbb0 in eval_sub (form=form@entry=43559014) at eval.c:2147
#11 0x0000000000552be9 in internal_lisp_condition_case (var=<optimized
out>,
bodyform=43559014, handlers=<optimized out>) at eval.c:1313
#12 0x0000000000584d3e in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=140737488343176, args=0x8f)
at bytecode.c:1169
#13 0x0000000000550017 in funcall_lambda (fun=30464509, nargs=nargs@entry
=0,
arg_vector=0x7fffffffd290, arg_vector@entry=0x7fffffffd220) at
eval.c:2973
#14 0x00000000005502db in Ffuncall (nargs=1, args=0x7fffffffd218)
at eval.c:2866
#15 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=23, args=0x1) at
bytecode.c:919
#16 0x0000000000550017 in funcall_lambda (fun=9032693, nargs=nargs@entry=2,
arg_vector=0x7fffffffd460, arg_vector@entry=0x7fffffffd3c0) at
eval.c:2973
#17 0x00000000005502db in Ffuncall (nargs=3, args=0x7fffffffd3b8)
at eval.c:2866
#18 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=140737488343984, args=0x3)
at bytecode.c:919
#19 0x0000000000550017 in funcall_lambda (fun=9031493, nargs=nargs@entry=0,
arg_vector=0x7fffffffd5b0, arg_vector@entry=0x7fffffffd550) at
eval.c:2973
#20 0x00000000005502db in Ffuncall (nargs=1, args=0x7fffffffd548)
at eval.c:2866
#21 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=0, args=0x1) at bytecode.c:919
#22 0x0000000000550017 in funcall_lambda (fun=9021325, nargs=nargs@entry=0,
arg_vector=0x7fffffffd8a0, arg_vector@entry=0x7fffffffd6a8) at
eval.c:2973
#23 0x00000000005502db in Ffuncall (nargs=1, args=0x7fffffffd6a0)
at eval.c:2866
#24 0x000000000054fbb0 in eval_sub (form=form@entry=43560838) at eval.c:2147
#25 0x0000000000552be9 in internal_lisp_condition_case (var=<optimized
out>,
bodyform=43560838, handlers=<optimized out>) at eval.c:1313
#26 0x0000000000584d3e in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=140737488345104, args=0x8f)
at bytecode.c:1169
#27 0x0000000000550017 in funcall_lambda (fun=9021085, nargs=nargs@entry=1,
arg_vector=0x7fffffffda40, arg_vector@entry=0x7fffffffd9b8) at
eval.c:2973
#28 0x00000000005502db in Ffuncall (nargs=2, args=0x7fffffffd9b0)
at eval.c:2866
#29 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=140737488345512, args=0x2)
at bytecode.c:919
#30 0x0000000000550017 in funcall_lambda (fun=9019749, nargs=nargs@entry=2,
arg_vector=0x7fffffffdc20, arg_vector@entry=0x7fffffffdb68) at
eval.c:2973
#31 0x00000000005502db in Ffuncall (nargs=3, args=0x7fffffffdb60)
at eval.c:2866
#32 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=140737488345944, args=0x3)
at bytecode.c:919
#33 0x0000000000550017 in funcall_lambda (fun=9017533, nargs=nargs@entry=6,
arg_vector=0x7fffffffde00, arg_vector@entry=0x7fffffffdd60) at
eval.c:2973
#34 0x00000000005502db in Ffuncall (nargs=7, args=0x7fffffffdd58)
at eval.c:2866
#35 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=140737488346448, args=0x7)
at bytecode.c:919
#36 0x0000000000550017 in funcall_lambda (fun=9015933, nargs=nargs@entry=4,
arg_vector=0x7fffffffdf80, arg_vector@entry=0x7fffffffdf00) at
eval.c:2973
#37 0x00000000005502db in Ffuncall (nargs=5, args=0x7fffffffdef8)
at eval.c:2866
#38 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=2, args=0x5) at bytecode.c:919
#39 0x0000000000550017 in funcall_lambda (fun=9010173, nargs=nargs@entry=2,
arg_vector=0x7fffffffe340, arg_vector@entry=0x7fffffffe068) at
eval.c:2973
#40 0x00000000005502db in Ffuncall (nargs=nargs@entry=3,
args=args@entry=0x7fffffffe060) at eval.c:2866
#41 0x00000000005516cc in Fapply (nargs=nargs@entry=2,
args=args@entry=0x7fffffffe100) at eval.c:2344
#42 0x0000000000551900 in apply1 (fn=fn@entry=16448530, arg=arg@entry
=43566262)
at eval.c:2578
#43 0x000000000054c4f3 in Fcall_interactively (function=16448530,
record_flag=12338034, keys=12372157) at callint.c:378
#44 0x000000000055049b in Ffuncall (nargs=<optimized out>,
args=<optimized out>) at eval.c:2812
#45 0x0000000000583d4d in exec_byte_code (bytestr=43494448,
vector=12582258,
maxdepth=14096928, args_template=2, nargs=140737488347808, args=0x4)
at bytecode.c:919
#46 0x0000000000550017 in funcall_lambda (fun=9528237, nargs=nargs@entry=1,
arg_vector=0x0, arg_vector@entry=0x7fffffffe428) at eval.c:2973
#47 0x00000000005502db in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7fffffffe420) at eval.c:2866
#48 0x00000000005505fa in call1 (fn=<optimized out>, arg1=<optimized out>)
at eval.c:2604
#49 0x00000000004eea6d in command_loop_1 () at keyboard.c:1552
#50 0x000000000054e95e in internal_condition_case (
bfun=bfun@entry=0x4ee6e0 <command_loop_1>, handlers=<optimized out>,
hfun=hfun@entry=0x4e5770 <cmd_error>) at eval.c:1344
#51 0x00000000004e0f0e in command_loop_2 (ignore=ignore@entry=12338034)
at keyboard.c:1170
#52 0x000000000054e86b in internal_catch (tag=12384578,
func=func@entry=0x4e0ef0 <command_loop_2>, arg=12338034) at eval.c:1108
#53 0x00000000004e5397 in command_loop () at keyboard.c:1149
#54 recursive_edit_1 () at keyboard.c:777
#55 0x00000000004e5682 in Frecursive_edit () at keyboard.c:841
#56 0x0000000000416c95 in main (argc=<optimized out>, argv=0x7fffffffe7c8)
at emacs.c:1637
[-- Attachment #2: Type: text/html, Size: 9322 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Crash when loading GIF images
2013-12-31 8:18 Crash when loading GIF images Elias Mårtenson
@ 2013-12-31 8:50 ` Eli Zaretskii
2013-12-31 9:09 ` Elias Mårtenson
0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2013-12-31 8:50 UTC (permalink / raw)
To: Elias Mårtenson; +Cc: emacs-devel
> Date: Tue, 31 Dec 2013 16:18:35 +0800
> From: Elias Mårtenson <lokedhs@gmail.com>
>
> Since at least several months, after compiling Emacs from source on Arch
> Linux, the entire Emacs session crashes when displaying any GIF image. The
> stack trace shows the crash happening inside giflib.
>
> Forcing Emacs to build with libungif instead fixes the problem, so it has
> something to do with how Emacs uses giflib.
What kind of GIF library did you use before this started to happen?
Was it an older version of giflib, or libungif?
> Reproducing the error is very easy for me. All I have to do is to open any
> GIF file and it immediately crashes.
>
> The version of giflib in my release of Arch Linux is: 5.0.5
Are you sure the header files you used for building Emacs against
giflib are consistent with the library? Latest versions of giflib use
different signatures of several functions used by Emacs, creating a
binary incompatibility with previous versions, so if you are using
headers that specify old signatures, you will get crashes.
FWIW, I'm using giflib 5.0.5 (not on GNU/Linux, though) with Emacs
without any problems.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Crash when loading GIF images
2013-12-31 8:50 ` Eli Zaretskii
@ 2013-12-31 9:09 ` Elias Mårtenson
2013-12-31 19:26 ` Glenn Morris
0 siblings, 1 reply; 5+ messages in thread
From: Elias Mårtenson @ 2013-12-31 9:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On 31 December 2013 16:50, Eli Zaretskii <eliz@gnu.org> wrote:
> > Reproducing the error is very easy for me. All I have to do is to open
> any
> > GIF file and it immediately crashes.
> >
> > The version of giflib in my release of Arch Linux is: 5.0.5
>
> Are you sure the header files you used for building Emacs against
> giflib are consistent with the library? Latest versions of giflib use
> different signatures of several functions used by Emacs, creating a
> binary incompatibility with previous versions, so if you are using
> headers that specify old signatures, you will get crashes.
>
> FWIW, I'm using giflib 5.0.5 (not on GNU/Linux, though) with Emacs
> without any problems.
>
Yes, you are right of course. Thank you. I'm sorry for wasting your time.
I just now (just before I read your reply) discovered that I had an old
gif_lib.h lying around in /usr/local/include that configure had picked up
instead of the real one in /usr/include.
Regards,
Elias
[-- Attachment #2: Type: text/html, Size: 1540 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-01-01 13:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-31 8:18 Crash when loading GIF images Elias Mårtenson
2013-12-31 8:50 ` Eli Zaretskii
2013-12-31 9:09 ` Elias Mårtenson
2013-12-31 19:26 ` Glenn Morris
2014-01-01 13:47 ` Elias Mårtenson
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).