[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#33524: closed (27.0.50; Suspicious code in flymake

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#33524: closed (27.0.50; Suspicious code in flymake-proc around temporary directories)
Date: Mon, 17 Dec 2018 10:59:02 +0000

Your message dated Mon, 17 Dec 2018 11:58:02 +0100
with message-id <address@hidden>
and subject line Re: bug#33524: 27.0.50; Suspicious code in flymake-proc around 
temporary directories
has caused the debbugs.gnu.org bug report #33524,
regarding 27.0.50; Suspicious code in flymake-proc around temporary directories
to be marked as done.

(If you believe you have received this mail in error, please contact

33524: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=33524
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 27.0.50; Suspicious code in flymake-proc around temporary directories Date: Tue, 27 Nov 2018 17:37:05 +0100
I've noticed that the temporary directory code in flymake-proc has
issues with remote filenames.  For example:

$ emacs -Q -batch -l flymake-proc --eval='(print 
(flymake-proc-create-temp-with-folder-structure "/:/dir" nil))'


Clearly that's not what was intended.  Rather, this should create the
directory structure on the remote machine.

If we use that filename:

mkdir -p /tmp/:/dir

then stuff will generally work, but trying to remove it will cause an
endless loop and try to remove /dir and /:

$ emacs -Q -batch -l flymake-proc --eval='(flymake-proc--delete-temp-directory 
Error [flymake-proc *scratch*]: Failed to delete dir /dir, error ignored
Error [flymake-proc *scratch*]: Failed to delete dir /, error ignored
Error [flymake-proc *scratch*]: Failed to delete dir /, error ignored
[...infinite loop...]
lisp.h:1485: Emacs fatal error: assertion failed: 0 <= nchars

The assertion failure seems to be a different issue, but this bug
focuses on the problematic behavior of flymake-proc.  The code for these
functions looks really suspicious and seems to make lots of incorrect
assumptions (about whether temporary-file-directory ends in a slash,
that all files are local, etc.).  Especially the infinite loop in
flymake-proc--delete-temp-directory causes trouble because the only way
out of it is sending a signal to the Emacs process.

In GNU Emacs 27.0.50 (build 46, x86_64-pc-linux-gnu, GTK+ Version 3.22.24)
 of 2018-11-27
Repository revision: e02d375cb6670e2306b9c67d7f6fd2dd1d1b2711
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Debian GNU/Linux buster/sid

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Eager macro-expansion failure: (wrong-number-of-arguments (2 . 2) 4)

Configured using:
 'configure --without-threads --enable-gcc-warnings=warn-only
 --enable-gtk-deprecation-warnings --without-pop --with-mailutils
 --enable-checking --enable-check-lisp-object-type --with-modules
 'CFLAGS=-O0 -ggdb3''

Configured features:

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec epa derived epg epg-config
gnus-util rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst pcase ffap
thingatpt url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map url-vars subr-x rx gnutls puny
seq byte-opt gv bytecomp byte-compile cconv dbus xml cl-loaddefs cl-lib
elec-pair mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors 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 composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray 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 inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 109009 5313)
 (symbols 48 21762 1)
 (strings 32 32871 2004)
 (string-bytes 1 894311)
 (vectors 16 16454)
 (vector-slots 8 533506 11914)
 (floats 8 52 65)
 (intervals 56 230 0)
 (buffers 992 12))

Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

If you received this communication by mistake, please don’t forward it to
anyone else (it may contain confidential or privileged information), please
erase all copies of it, including all attachments, and please let the sender
know it went to the wrong person.  Thanks.

--- End Message ---
--- Begin Message --- Subject: Re: bug#33524: 27.0.50; Suspicious code in flymake-proc around temporary directories Date: Mon, 17 Dec 2018 11:58:02 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
Michael Albinus <address@hidden> writes:


>> No, it looks great, for all I know... Which is very little :-)
>> Flymake-proc is the "legacy" backend that I packed up in a file. It
>> probably has many such bugs.
> Thanks for the reply. If Philipp confirms the solution, I'll push it to
> master.

I've pushed the patch to the master branch, closing the bug.

>> Thanks very much Michael and Philipp,
>> João

Best regards, Michael.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]