Issue373

classification
Title Crash entering article in Gnus (libpng?)
Type defect Module core code 21.5
Severity inconvenience Platform N/A
Keywords Nosy List james, mike.kupfer, stephen
explanation
process
These controls should only be changed by committers and tracker administrators.
Status closed   Reason fixed
Superseder [Bug: 21.5-b29] usenet article freezes XEmacs
View: 570
 
Priority normal   Assigned To

Created on 2008-05-06.03:14:40 by stephen, last changed 2009-09-24.16:09:54 by stephen.

Files
File name Uploaded Type Edit Remove
face.png asjo, 2008-05-06.13:53:19 image/png
Messages
msg1853 [hidden] ([hidden]) Date: 2009-09-24.14:36:51
  Message-ID: <1253803011.66.0.151742766884.issue373@xemacs.org>
Adam reports this is fixed by the patch that fixes issue570.  Closing this 
one (issue570 will stay open until the patch is applied to 21.4).
msg1177 [hidden] ([hidden]) Date: 2009-04-18.03:01:39
  Message-ID: <1240023699.96.0.853533454162.issue373@xemacs.org>
Not reproducible (either the original crash or the one I mentioned in
msg1176) on OpenSolaris 2008.11 with XEmacs 21.4.22.  I haven't figured
out what version of libpng that corresponds to.
msg1176 [hidden] ([hidden]) Date: 2009-04-17.03:11:59
  Message-ID: <1239937919.66.0.872834483428.issue373@xemacs.org>
FWIW, the face.png in the Files area makes my XEmacs 21.4.22 and
21.5.28 crash on openSUSE 11.0, which claims to have a fix for the
libpng vulnerability mentioned below (2008-1382).

When I run 21.4.22 under gdb, I get 

*** glibc detected *** /usr/local/bin/xemacs: munmap_chunk(): invalid
pointer: 0x08ec25d0 ***

followed by a C backtrace and a dump of the memory map.

======= Backtrace: =========
/lib/libc.so.6[0xb7b57fc4]
/lib/libc.so.6[0xb7b59059]
/usr/local/bin/xemacs[0x8132497]
/usr/local/bin/xemacs[0x813067e]
/usr/local/bin/xemacs[0x8130b96]
/usr/local/bin/xemacs[0x80bfb99]
/usr/local/bin/xemacs(internal_catch+0x91)[0x80bca01]
/usr/local/bin/xemacs(call_with_suspended_errors+0x17a)[0x80bfe4a]
/usr/local/bin/xemacs(Fmake_image_instance+0x5d)[0x812749d]
...

With 21.5.28 I just get a SEGV, with no error reported by glibc.

I also ran into an email message with a Face header that crashes
21.4.22 and 21.5.28 with Gnus and MH-E 8 (which uses a lot of display
code from Gnus), though it doesn't crash 21.4.22 with VM.  (It doesn't
display the face with VM, either.)  I get this complaint:

*** glibc detected *** /usr/local/bin/xemacs: double free or corruption
(!prev): 0x09e96d88 ***

A partial backtrace from 21.5.28 looks like

======= Backtrace: =========
/lib/libc.so.6[0xb7a24fc4]
/lib/libc.so.6(cfree+0x9c)[0xb7a2695c]
/usr/lib/libpng12.so.0(png_free_default+0x28)[0xb7eec118]
/usr/lib/libpng12.so.0(png_free+0x4c)[0xb7eec16c]
/usr/lib/libpng12.so.0[0xb7ed21c4]
/lib/libz.so.1(inflateEnd+0x41)[0xb7ea1c31]
/usr/lib/libpng12.so.0[0xb7ee1841]
/usr/lib/libpng12.so.0(png_destroy_read_struct+0x7b)[0xb7ee19db]
/usr/bin/xemacs[0x81399e0]
/usr/bin/xemacs(unbind_to_hairy+0x28)[0x80d6ac8]
/usr/bin/xemacs(unbind_to_1+0x68)[0x80d6bd8]
/usr/bin/xemacs[0x813a7ad]
/usr/bin/xemacs[0x8137152]
/usr/bin/xemacs[0x8137778]
/usr/bin/xemacs[0x80d569b]
/usr/bin/xemacs(call_with_condition_handler+0x83)[0x80d9a23]
/usr/bin/xemacs[0x80d9a65]
/usr/bin/xemacs(internal_catch+0xc1)[0x80d7881]
/usr/bin/xemacs(call_trapping_problems+0x312)[0x80dac52]
/usr/bin/xemacs(call_with_suspended_errors+0x115)[0x80db745]
/usr/bin/xemacs[0x81c1de9]
/usr/bin/xemacs[0x81c23bf]
/usr/bin/xemacs(glyph_image_instance+0x43)[0x8131f73]
/usr/bin/xemacs[0x813831e]
/usr/bin/xemacs(get_glyph_cachel_index+0x8c)[0x813851c]
/usr/bin/xemacs[0x819318e]
/usr/bin/xemacs[0x8193bf2]
/usr/bin/xemacs[0x8199e60]
/usr/bin/xemacs[0x819d4ee]
/usr/bin/xemacs[0x81a0bf6]
/usr/bin/xemacs[0x81a1921]
/usr/bin/xemacs[0x81a06d9]
/usr/bin/xemacs(redisplay_frame+0x134)[0x81a1a74]

A partial backtrace from 21.4.22 looks like

======= Backtrace: =========
/lib/libc.so.6[0xb7b9afc4]
/lib/libc.so.6(cfree+0x9c)[0xb7b9c95c]
/usr/local/bin/xemacs<png_instantiate_unwind+93>[0x813283d]
/usr/local/bin/xemacs(unbind_to+0xc9)[0x80bd6f9]
/usr/local/bin/xemacs[0x813252e]
/usr/local/bin/xemacs[0x813067e]
/usr/local/bin/xemacs[0x8131090]
/usr/local/bin/xemacs[0x80bfbf3]
/usr/local/bin/xemacs(internal_catch+0x91)[0x80bca01]
/usr/local/bin/xemacs(call_with_suspended_errors+0x17a)[0x80bfe4a]
/usr/local/bin/xemacs[0x8192273]
/usr/local/bin/xemacs(specifier_instance+0x137)[0x8194dd7]
/usr/local/bin/xemacs(glyph_image_instance+0x43)[0x8127583]
/usr/local/bin/xemacs(invalidate_glyph_geometry_maybe+0x7c)[0x812763c]
/usr/local/bin/xemacs[0x816d78c]
/usr/local/bin/xemacs[0x8175ccb]
/usr/local/bin/xemacs[0x817762b]
/usr/local/bin/xemacs[0x8179a2f]
/usr/local/bin/xemacs[0x81797d9]
/usr/local/bin/xemacs(redisplay_frame+0x104)[0x817ab74]

or


======= Backtrace: =========
/lib/libc.so.6[0xb7b3dfc4]
/lib/libc.so.6(cfree+0x9c)[0xb7b3f95c]
/usr/lib/libpng12.so.0(png_free_default+0x28)[0xb7fee118]
/usr/lib/libpng12.so.0(png_free+0x4c)[0xb7fee16c]
/usr/lib/libpng12.so.0[0xb7fe35fd]
/usr/lib/libpng12.so.0(png_destroy_read_struct+0x7b)[0xb7fe39db]
/usr/local/bin/xemacs<png_instantiate_unwind+64>[0x8132820]
/usr/local/bin/xemacs(unbind_to+0xc9)[0x80bd6f9]
/usr/local/bin/xemacs<png_instantiate+910>[0x813252e]
/usr/local/bin/xemacs<instantiate_image_instantiator+878>[0x813067e]
/usr/local/bin/xemacs<image_instantiate+944>[0x8131090]
/usr/local/bin/xemacs<call_with_suspended_errors+579>[0x80bfbf3]
/usr/local/bin/xemacs(internal_catch+0x91)[0x80bca01]
/usr/local/bin/xemacs(call_with_suspended_errors+0x17a)[0x80bfe4a]
/usr/local/bin/xemacs[0x8192273]
/usr/local/bin/xemacs(specifier_instance+0x137)[0x8194dd7]
/usr/local/bin/xemacs(glyph_image_instance+0x43)[0x8127583]
/usr/local/bin/xemacs(invalidate_glyph_geometry_maybe+0x7c)[0x812763c]
/usr/local/bin/xemacs[0x816d78c]
/usr/local/bin/xemacs[0x8175ccb]
/usr/local/bin/xemacs[0x817762b]
/usr/local/bin/xemacs[0x8179a2f]
/usr/local/bin/xemacs[0x81797d9]
/usr/local/bin/xemacs(redisplay_frame+0x104)[0x817ab74]

I don't know if this is related to the original crash, but I wonder if
there's a memory management issue, either in XEmacs or libpng.
msg1094 [hidden] ([hidden]) Date: 2009-03-12.22:12:52
  Message-ID: <1236895972.34.0.49206613481.issue373@xemacs.org>
See also issue408, issue495.
msg719 [hidden] ([hidden]) Date: 2008-05-06.13:53:19
  Message-ID: <1210081999.51.0.309204311501.issue373@xemacs.org>
Attached is the PNG that triggers the problem - just loading
it with C-x C-f face.png RET invokes the crash on my machine.
msg718 [hidden] ([hidden]) Date: 2008-05-06.03:14:40
  Message-ID: <1210043680.89.0.379069352686.issue373@xemacs.org>
Crash trying to read an article in Gnus, reported by
asjo@koldfront.dk (Adam Sj√łgren) on xemacs-beta in
<87y76ue2mx.fsf@topper.koldfront.dk>.

There's a good chance it *is* libpng: 
 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1382 
 
Note that this affects pretty much all libpng up to v1.2.26.
History
Date User Action Args
2009-09-24 16:09:54stephensetreason: fixed
2009-09-24 14:36:51stephensetstatus: assigned -> closed
assignedto: james -> stephen
superseder: + [Bug: 21.5-b29] usenet article freezes XEmacs
messages: + msg1853
2009-04-18 03:01:39mike.kupfersetmessages: + msg1177
2009-04-17 03:11:59mike.kupfersetmessages: + msg1176
2009-03-12 22:12:52mike.kupfersetnosy: + mike.kupfer
messages: + msg1094
2008-05-06 13:53:19asjosetfiles: + face.png
messages: + msg719
2008-05-06 03:14:40stephencreate