From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: "corrupted size vs. prev_size" Date: Tue, 12 Apr 2022 14:44:37 +0300 Message-ID: <831qy25xwa.fsf@gnu.org> References: <87mtgqworp.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25392"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 12 13:47:46 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neEzp-0006O4-8G for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 13:47:45 +0200 Original-Received: from localhost ([::1]:56104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1neEzo-0000XC-72 for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 07:47:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33320) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neEwm-0006QP-KS for emacs-devel@gnu.org; Tue, 12 Apr 2022 07:44:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34694) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neEwl-0003wE-5K; Tue, 12 Apr 2022 07:44:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=l4uwBrrhzgReO8DJ1AMPZJUuEBQ6sfP0qkyU5jKFIZU=; b=iwu5oI+Wy0ic ib9pGTPvPI39rbEZ7vPnAPzTkws6oq1epmCzY9z8iVtoOoGUnpDJ+BMaq/F+hqnjcWHjArBoeqqem Y/y70pwW4kSHELbE5+DqTzxNWrnqDGf54YdOm4XYwUAki0AGzMM7Gz7hzqkmAtMAr1mz46oAbzkzo kqhY0hCFNjSfFucLNpIseP3sdGQJI8DBByJdnQe2qlh6Z7qMh5VJUSQWgNPRH92Zt3+hCXazyENFS i2Xtbe41QhWGPMyMnxFdEACJJbblkRaB98zbtC9hC3MVRQuEbLc1dm0oPYxLjnLS4zJhPQVAhFOxS XEgr57D6CwjF6/wnIRPnjA==; Original-Received: from [87.69.77.57] (port=4978 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neEwk-0000p7-LD; Tue, 12 Apr 2022 07:44:34 -0400 In-Reply-To: <87mtgqworp.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 12 Apr 2022 12:59:38 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:288294 Archived-At: > From: Lars Ingebrigtsen > Date: Tue, 12 Apr 2022 12:59:38 +0200 > > After the recent GIF/WebP caching changes, I sometimes get "corrupted > size vs. prev_size" and Emacs then hangs, so I guess I'm messing up > something in the memory allocation/freeing/writing bits somewhere. > > But I'm getting it very, very rarely -- like one out of every thirty > times with a bunch of WebP/GIF images, so it's hard to track down. > Connecting to the hung Emacs isn't very informative: > > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7f303a430000 (LWP 84136) "emacs" 0x00007f303d54e1f3 in __pselect (nfds=22, readfds=0x7ffd058d69e0, writefds=0x7ffd058d6a60, > exceptfds=0x0, timeout=0x7ffd058d6800, sigmask=) > at ../sysdeps/unix/sysv/linux/pselect.c:52 > 2 Thread 0x7f3039229640 (LWP 84137) "gmain" 0x00007f303d54b87f in __GI___poll (fds=0x561b63028870, nfds=2, timeout=-1) > at ../sysdeps/unix/sysv/linux/poll.c:29 > 3 Thread 0x7f303898c640 (LWP 84138) "gdbus" 0x00007f303d54b87f in __GI___poll (fds=0x561b63452d20, nfds=3, timeout=-1) > at ../sysdeps/unix/sysv/linux/poll.c:29 > 4 Thread 0x7f3033fff640 (LWP 84139) "dconf worker" 0x00007f303d54b87f in __GI___poll (fds=0x561b634be7d0, nfds=1, timeout=-1) > at ../sysdeps/unix/sysv/linux/poll.c:29 > > I've stared at the code for some time now to see whether I can track the > problem down that way -- perhaps I've got some lifetime issues; > deallocating webp iterators twice, for instance, or something similar in > the gif code. Does anybody else see something obviously wonky in that > code in gif_load or webp_load? I didn't see anything obviously wonky, but I can report that I had one segfault in webp_load. I couldn't reproduce it no matter how hard I tried. Here's the backtrace from that crash, in case it helps (I doubt that): Thread 1 received signal SIGSEGV, Segmentation fault. 0x61b4c91a in ?? () from D:\usr\bin\libwebp-7.dll (gdb) bt #0 0x61b4c91a in ?? () from D:\usr\bin\libwebp-7.dll #1 0x61b4ce35 in ?? () from D:\usr\bin\libwebp-7.dll #2 0x61b4d795 in ?? () from D:\usr\bin\libwebp-7.dll #3 0x6bdc18f5 in ?? () from D:\usr\bin\libwebpdemux-2.dll #4 0x013d9d13 in webp_load (f=0x7575c68, img=0x7adfd88) at image.c:9467 #5 0x013cf399 in lookup_image (f=0x7575c68, spec=XIL(0xc000000006791ac0), face_id=0) at image.c:2666 #6 0x0104d011 in handle_single_display_spec (it=0x82ac68, spec=XIL(0xc000000006791ac0), object=XIL(0xa000000007697960), overlay=XIL(0), position=0x82ad50, bufpos=1, display_replaced=0, frame_window_p=true, enable_eval_p=true) at xdisp.c:6012 #7 0x01049c42 in handle_display_spec (it=0x82ac68, spec=XIL(0xc000000006791ac0), object=XIL(0xa000000007697960), overlay=XIL(0), position=0x82ad50, bufpos=1, frame_window_p=true) at xdisp.c:5475 #8 0x010490fb in handle_display_prop (it=0x82ac68) at xdisp.c:5383 #9 0x010449c2 in handle_stop (it=0x82ac68) at xdisp.c:3875 #10 0x010515db in reseat (it=0x82ac68, pos=..., force_p=true) at xdisp.c:7336 #11 0x01043c26 in init_iterator (it=0x82ac68, w=0x7575e80, charpos=1, bytepos=1, row=0x7635008, base_face_id=DEFAULT_FACE_ID) at xdisp.c:3476 #12 0x01043cbe in start_display (it=0x82ac68, w=0x7575e80, pos=...) at xdisp.c:3492 #13 0x0107adfc in try_window (window=XIL(0xa000000007575e80), pos=..., flags=1) at xdisp.c:20019 #14 0x01077a6e in redisplay_window (window=XIL(0xa000000007575e80), just_this_one_p=false) at xdisp.c:19432 #15 0x0106f1e3 in redisplay_window_0 (window=XIL(0xa000000007575e80)) at xdisp.c:17077 #16 0x0126c924 in internal_condition_case_1 ( bfun=0x106f18b , arg=XIL(0xa000000007575e80), handlers=XIL(0xc0000000060b349c), hfun=0x106f148 ) at eval.c:1474 #17 0x0106f10a in redisplay_windows (window=XIL(0xa000000007575e80)) at xdisp.c:17057 #18 0x0106d96a in redisplay_internal () at xdisp.c:16525 #19 0x0106e7fb in redisplay_preserve_echo_area (from_where=8) at xdisp.c:16878 #20 0x0118d249 in detect_input_pending_run_timers (do_display=true) at keyboard.c:10758 #21 0x012fa97a in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5695 #22 0x01012764 in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at dispnew.c:6154 #23 0x01171b37 in read_char (commandflag=1, map=XIL(0xc000000007679cb0), prev_event=XIL(0), used_mouse_menu=0x82f49f, end_time=0x0) at keyboard.c:2837 #24 0x0118a950 in read_key_sequence (keybuf=0x82f770, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9932 #25 0x0116c667 in command_loop_1 () at keyboard.c:1401 #26 0x0126c83a in internal_condition_case (bfun=0x116bf54 , handlers=XIL(0x90), hfun=0x116af52 ) at eval.c:1450 #27 0x0116b9c1 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1142 #28 0x0126b6d9 in internal_catch (tag=XIL(0xfb70), func=0x116b98a , arg=XIL(0x90)) at eval.c:1180 #29 0x0116b944 in command_loop () at keyboard.c:1120 #30 0x0116a9b2 in recursive_edit_1 () at keyboard.c:729 #31 0x0116ac50 in Frecursive_edit () at keyboard.c:812 #32 0x01165c0a in main (argc=4, argv=0xa42990) at emacs.c:2447 Lisp Backtrace: "redisplay_internal (C function)" (0x0)