GNU bug report logs - #44350
28.0.50; Emacs aborts when launching Gnus on MacOs

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 44350 in the body.
You can then email your comments to 44350 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: 陈志伟 <chenzhiwei03 <at> kuaishou.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 28.0.50; Emacs aborts when launching Gnus on MacOs
Date: Sat, 31 Oct 2020 13:11:11 +0000

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

In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H2))
 of 2020-10-31 built on Youmu.local
Repository revision: 7f30bf72066514db44cf00b20f807bb360e1b968
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7

The stacktrace, it looks like a librsvg bug.

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff6cc6d33a libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff6cd29e60 libsystem_pthread.dylib`pthread_kill + 430
    frame #2: 0x00007fff6cbf4808 libsystem_c.dylib`abort + 120
    frame #3: 0x000000010ea56e89 librsvg-2.2.dylib`std::sys::unix::abort_internal::h678855dc4c2872cf + 9
    frame #4: 0x000000010ea6c8a0 librsvg-2.2.dylib`std::sys_common::util::abort::h3a321678d7dec175 + 80
    frame #5: 0x000000010ea34263 librsvg-2.2.dylib`rust_panic + 99
    frame #6: 0x000000010ea340ff librsvg-2.2.dylib`std::panicking::rust_panic_with_hook::h747c3c133ec2d635 + 383
    frame #7: 0x000000010ea33c72 librsvg-2.2.dylib`rust_begin_unwind + 130
    frame #8: 0x000000010eabdb9b librsvg-2.2.dylib`std::panicking::begin_panic_fmt::he8a78d2c3d6ac241 + 59
    frame #9: 0x000000010e77f786 librsvg-2.2.dylib`cairo::context::Context::save::hdd59bf5e9cdc6eee + 134
    frame #10: 0x000000010e5e64d2 librsvg-2.2.dylib`_$LT$rsvg_internals..structure..Svg$u20$as$u20$rsvg_internals..element..Draw$GT$::draw::h1fbeae4cb4094026 + 2546
    frame #11: 0x000000010e5c7bc1 librsvg-2.2.dylib`_$LT$rsvg_internals..element..ElementInner$LT$T$GT$$u20$as$u20$rsvg_internals..element..Draw$GT$::draw::_$u7b$$u7b$closure$u7d$$u7d$::h205fe57f3c282030 + 65
    frame #12: 0x000000010e6d08cc librsvg-2.2.dylib`rsvg_internals::drawing_ctx::DrawingCtx::with_saved_transform::h3c002deb777ea777 + 204
    frame #13: 0x000000010e5ce450 librsvg-2.2.dylib`_$LT$rsvg_internals..element..Element$u20$as$u20$rsvg_internals..element..Draw$GT$::draw::h460591632f2f67d3 + 9904
    frame #14: 0x000000010e687383 librsvg-2.2.dylib`_$LT$rctree..Node$LT$rsvg_internals..node..NodeData$GT$$u20$as$u20$rsvg_internals..node..NodeDraw$GT$::draw::h7903ca2c9a85fb9d + 259
    frame #15: 0x000000010e6d82e4 librsvg-2.2.dylib`rsvg_internals::drawing_ctx::DrawingCtx::draw_node_from_stack::haf30e698e310a278 + 244
    frame #16: 0x000000010e6cb25b librsvg-2.2.dylib`rsvg_internals::drawing_ctx::draw_tree::hb886746764b14e39 + 1211
    frame #17: 0x000000010e69f47c librsvg-2.2.dylib`rsvg_internals::handle::Handle::get_geometry_for_layer::h167c0b807d13a3ce + 668
    frame #18: 0x000000010e579e94 librsvg-2.2.dylib`rsvg_rust_handle_get_geometry_for_layer + 548
    frame #19: 0x000000010d2c8981 Emacs`svg_load_image + 214
    frame #20: 0x000000010d2c44c2 Emacs`lookup_image + 759
    frame #21: 0x000000010d2c412f Emacs`Fimage_size + 59
    frame #22: 0x000000010d262fc6 Emacs`funcall_subr + 292
    frame #23: 0x000000010d26285d Emacs`Ffuncall + 646
    frame #24: 0x000000010d297314 Emacs`exec_byte_code + 1163
    frame #25: 0x000000010d2627fb Emacs`Ffuncall + 548
    frame #26: 0x000000010d297314 Emacs`exec_byte_code + 1163
    frame #27: 0x000000010d2627fb Emacs`Ffuncall + 548
    frame #28: 0x000000010d297314 Emacs`exec_byte_code + 1163
    frame #29: 0x000000010d2627fb Emacs`Ffuncall + 548
    frame #30: 0x000000010d297314 Emacs`exec_byte_code + 1163
    frame #31: 0x000000010d2627fb Emacs`Ffuncall + 548
    frame #32: 0x000000010d25d99d Emacs`Ffuncall_interactively + 73
    frame #33: 0x000000010d26285d Emacs`Ffuncall + 646
    frame #34: 0x000000010d25eafc Emacs`Fcall_interactively + 4426
    frame #35: 0x000000010d262fc6 Emacs`funcall_subr + 292
    frame #36: 0x000000010d26285d Emacs`Ffuncall + 646
    frame #37: 0x000000010d297314 Emacs`exec_byte_code + 1163
    frame #38: 0x000000010d2627fb Emacs`Ffuncall + 548
    frame #39: 0x000000010d262c45 Emacs`call1 + 46
    frame #40: 0x000000010d1f642d Emacs`command_loop_1 + 1426
    frame #41: 0x000000010d2613e7 Emacs`internal_condition_case + 84
    frame #42: 0x000000010d202e36 Emacs`command_loop_2 + 37
    frame #43: 0x000000010d261072 Emacs`internal_catch + 74
    frame #44: 0x000000010d302233 Emacs`recursive_edit_1.cold.1 + 69
    frame #45: 0x000000010d1f58c3 Emacs`recursive_edit_1 + 217
    frame #46: 0x000000010d1f59cd Emacs`Frecursive_edit + 226
    frame #47: 0x000000010d1f4ef7 Emacs`main + 7543
    frame #48: 0x00007fff6cb25cc9 libdyld.dylib`start + 1

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 陈志伟 <chenzhiwei03 <at> kuaishou.com>
Cc: 44350 <at> debbugs.gnu.org
Subject: Re: bug#44350: 28.0.50; Emacs aborts when launching Gnus on MacOs
Date: Sun, 01 Nov 2020 00:10:48 +0100

陈志伟 <chenzhiwei03 <at> kuaishou.com> writes:

> `rsvg_rust_handle_get_geometry_for_layer + 548

This should now be fixed on the trunk.

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

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

From: 陈志伟 <chenzhiwei03 <at> kuaishou.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "44350 <at> debbugs.gnu.org" <44350 <at> debbugs.gnu.org>
Subject: Re: bug#44350: 28.0.50; Emacs aborts when launching Gnus on MacOs
Date: Mon, 2 Nov 2020 03:40:02 +0000

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

Thanks, looks like it’s fixed in this commit [1].

But I’m confused that librsvg has handled when out_logical_rect is NULL [2].

[1]: https://github.com/emacs-mirror/emacs/commit/9405cd84a6309f780e76c11a4c79709aa8a4f44f
[2]: https://gitlab.gnome.org/GNOME/librsvg/-/blob/master/librsvg/c_api.rs#L1943

--
Zhiwei Chen


On Nov 1, 2020, at 7:10 AM, Lars Ingebrigtsen <larsi <at> gnus.org<mailto:larsi <at> gnus.org>> wrote:

陈志伟 <chenzhiwei03 <at> kuaishou.com<mailto:chenzhiwei03 <at> kuaishou.com>> writes:

`rsvg_rust_handle_get_geometry_for_layer + 548

This should now be fixed on the trunk.

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

[Message part 2 (text/html, inline)]

Previous Next

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