In my home directory ~/.emacs is symbolic link to ~/.init-files/.emacs ---------------------------------------------------------------------- yasu@rolling-vm-freebsd1[1004]% ls -l ~/.emacs lrwxr-xr-x 1 yasu user 18 Jan 6 2015 /home/yasu/.emacs@ -> .init-files/.emacs yasu@rolling-vm-freebsd1[1005]% ---------------------------------------------------------------------- And after update editors/emacs-devel to ports e7edd97198e4, following error message is displayed in *Warning* buffer when I start emacs. ---------------------------------------------------------------------- Warning (initialization): An error occurred while loading ‘/home/yasu/.emacs’: Wrong type argument: number-or-marker-p, nil ---------------------------------------------------------------------- The error disappears if I do `rm ~/.emacs; cp ~/.init-files/.emacs ~/.emacs`. And it only happens with 14-CURRENT. ---------------------------------------------------------------------- yasu@rolling-vm-freebsd1[1007]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n249811-a36230f75e0: Sat Oct 2 01:34:30 JST 2021 rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1008]% ---------------------------------------------------------------------- With 13.0-RELEASE and 12.2-RELEASE emacs starts without any error.
(In reply to Yasuhiro Kimura from comment #0) Thanks for the report. Could you share the backtrace from `emacs --debug-init` ? And also could you try with $HOME/.emacs symlinking to an empty file, and see if that generates a warnning too. Essentially, I'm trying to do an equivalent of "emacs -q". Thanks!
(In reply to Ashish SHUKLA from comment #1) If I start emacs with `--debug-init' option, then following backtrace is displayed in *Backtrace* buffer. ---------------------------------------------------------------------- Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) hack-elisp-shorthands("/home/yasu/.emacs") load-with-shorthands-and-code-conversion("/home/yasu/.emacs" "/home/yasu/.emacs" t t) load("~/.emacs" noerror nomessage) startup--load-user-init-file(#f(compiled-function () #<bytecode -0x17392be6705c7ab>) #f(compiled-function () #<bytecode -0x1f3c686ddc6fc675>) t) command-line() normal-top-level() ---------------------------------------------------------------------- And the error still happens even if ~/.emacs is symbolic link to empty file. According to the backtrace I did following test ---------------------------------------------------------------------- yasu@rolling-vm-freebsd1[1092]% cd /tmp yasu@rolling-vm-freebsd1[1093]% ls -l foo.el bar.el lrwxr-xr-x 1 yasu wheel 6 Oct 3 07:56 bar.el@ -> foo.el -rw-r--r-- 1 yasu wheel 0 Oct 3 07:56 foo.el yasu@rolling-vm-freebsd1[1094]% ---------------------------------------------------------------------- As you can see /tmp/foo.el is empty file and /tmp/bar.el is symbolic link to it. I started emacs with `emacs -Q` and evaluated following 2 s-expressions in *scratch* buffer. (hack-elisp-shorthands "/tmp/foo.el") (hack-elisp-shorthands "/tmp/bar.el") The former returned nil, and the latter resulted in error with "Wrong type argument: number-or-marker-p, nil". So it seems the source of problem is `(hack-elisp-shorthands "PATH")` results in error if PATH is symbolic link to normal file.
(In reply to Yasuhiro Kimura from comment #2) `hack-elisp-shorthands` is defined in lisp/international/mule.el as following. ---------------------------------------------------------------------- (defun hack-elisp-shorthands (fullname) "Return value of the `elisp-shorthands' file-local variable in FULLNAME. FULLNAME is the absolute file name of an Elisp .el file which potentially specifies a file-local value for `elisp-shorthands'. The Elisp code in FULLNAME isn't read or evaluated in any way, except for extraction of the buffer-local value of `elisp-shorthands'." (let ((size (nth 7 (file-attributes fullname)))) (with-temp-buffer (insert-file-contents fullname nil (max 0 (- size 3000)) size) (goto-char (point-max)) (let* ((found (search-backward-regexp "elisp-shorthands:[ \t]*" 0 t)) (val (and found (goto-char (match-end 0)) (ignore-errors (read (current-buffer))))) (probe val) aux) (catch 'done (when (consp probe) (while (setq aux (pop probe)) (unless (and (consp aux) (stringp (car aux)) (stringp (cdr aux))) (throw 'done nil))) val)))))) ---------------------------------------------------------------------- In this function `file-attributes` is used to get attributes of file. And the behavior of the function is different between 14-CURRENT and 13.0-REELASE. As explained before '~/.emacs' is symbolic link to '~/.init-files/.emacs' in my home directory. And if I evaluate '(file-attributes (expand-file-name "~/.emacs"))' on 13.0-RELEASE, I get following result. ---------------------------------------------------------------------- ("/home/yasu/.init-files/.emacs" 1 1000 1000 (24921 3099 201298 0) (24921 3099 201298 0) (24921 3099 201298 0) 29 "lrwxr-xr-x" t 471008 250081246980) ---------------------------------------------------------------------- It seems `file-attributes` returns attributes of '~/.emacs' itself (that is, attributes of symbolic link rather than the file it point to). On the other hand, evaluating the s-expression returns nil on 14-CURRENT. And it results in the error of `hack-elisp-shorthands`. `find-attributes` is built-in function defined in src/dired.c. But it isn't changed after January 1st of this year. ---------------------------------------------------------------------- yasu@eastasia[2045]% git log -n 1 -- src/dired.c commit ba05d005e5 Author: Paul Eggert <eggert@cs.ucla.edu> Date: Fri Jan 1 18:13:56 2021 Update copyright year to 2021 Run "TZ=UTC0 admin/update-copyright". yasu@eastasia[2045]% ---------------------------------------------------------------------- So it is strange the behavior changed after the update of editors/emacs-devel with ports e7edd97198e4.
I tried to reproduce on following host, and unable to: FreeBSD XXXXXXXXXXXXX 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n246034-e6ab1e365c0: Tue Apr 13 08:54:05 UTC 2021 root@XXXXXXXXXXXXXX:/usr/obj/usr/src/sys/CLUSTER14 amd64 (file-attributes (expand-file-name "~/.emacs")) => ("/home/ashish/.init-files/.emacs" 1 1228 493 (24921 45963 568856 0) (24921 45963 568856 0) (24921 45963 568856 0) 31 "lrwxr-xr-x" t 2643 14263890536310191404) % ls -la ~/.emacs ~/.init-files/.emacs lrwxr-xr-x 1 ashish devel 31 Oct 3 13:43 /home/ashish/.emacs -> /home/ashish/.init-files/.emacs -rw-r--r-- 1 ashish devel 37 Oct 3 13:38 /home/ashish/.init-files/.emacs I'll see if I can get a more recent 14-CURRENT host. Thanks!
Could you try the following C program on your 14-CURRENT host ? ------------------- /* rlnkat.c */ #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <strings.h> #define BUFSIZE 1024 int main(int argc, char** argv) { int i,ret; char buffer[BUFSIZE]; struct stat st; for(i = 1; i < argc; i++) { bzero( buffer, sizeof( buffer )); ret = fstatat( AT_FDCWD, argv[i], &st, AT_SYMLINK_NOFOLLOW ); if( -1 == ret ) { perror("fstatat"); continue; } if( S_ISLNK( st.st_mode )) { ret = readlinkat( AT_FDCWD, argv[i], buffer, sizeof( buffer )); if( -1 == ret ) { perror("readlinkat"); } else { fprintf(stderr, "%d. %s symlink to %s\n", i, argv[i], buffer ); } } else { fprintf( stderr, "%d. %s (is directory: %d)\n", i, argv[i], S_ISDIR( st.st_mode)); } } return 0; } ------------------------------------ With following filesystem contents: lrwxr-xr-x 1 ashish devel 31B Oct 3 13:43 .emacs -> /home/ashish/.init-files/.emacs drwxr-xr-x 2 ashish devel 3B Oct 3 13:43 .init-files -rw-r--r-- 1 ashish devel 37B Oct 3 13:38 .init-files/.emacs It results in: % cc -o rlnkat rlnkat.c % ./rlnkat .emacs .init-files/.emacs .init-files 1. .emacs symlink to /home/ashish/.init-files/.emacs 2. .init-files/.emacs (is directory: 0) 3. .init-files (is directory: 1) Could you share output from your side ? This is to rule out any kernel-space changes. Thanks!
(In reply to Ashish SHUKLA from comment #5) I got following result. ---------------------------------------------------------------------- yasu@rolling-vm-freebsd1[1038]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n249811-a36230f75e0: Sat Oct 2 01:34:30 JST 2021 rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1039]% cc -o rlncat rlncat.c yasu@rolling-vm-freebsd1[1040]% ls -ld ~/.emacs ~/.init-files ~/.init-files/.emacs lrwxr-xr-x 1 yasu user 29 10月 3 10:49 /home/yasu/.emacs@ -> /home/yasu/.init-files/.emacs drwxr-xr-x 7 yasu user 20 10月 2 13:23 /home/yasu/.init-files/ -rw-r--r-- 1 yasu user 4838 10月 2 13:23 /home/yasu/.init-files/.emacs yasu@rolling-vm-freebsd1[1041]% ./rlncat ~/.emacs ~/.init-files ~/.init-files/.emacs 1. /home/yasu/.emacs symlink to /home/yasu/.init-files/.emacs 2. /home/yasu/.init-files (is directory: 1) 3. /home/yasu/.init-files/.emacs (is directory: 0) yasu@rolling-vm-freebsd1[1042]% ---------------------------------------------------------------------- I created 14-CURRENT amd64 main-n246034-e6ab1e365c environment and confirmed Emacs 29.0.50.20211001 starts without any error. So I'll do `git bisect` with /usr/src to decide when the error starts happening.
(In reply to Yasuhiro Kimura from comment #6) Before starting `git bisect` I updated host system from main-n246034-e6ab1e365c to main-n249811-a36230f75e0 and checked if emacs binary built on the former result in error if it is executed on the latter. Then emacs starts without error. Next I rebuilt all packages on main-n249811-a36230f75e0 and reinstalled them. Naturally error happened when I started Emacs. And finaly I reverted host system to main-n246034-e6ab1e365c and checked what happens if I executed emacs binary build on main-n249811-a36230f75e0. Then following message is displayed in *Warnings* buffer. ---------------------------------------------------------------------- Warning (initialization): An error occurred while loading `/home/yasu/.emacs': File error: Getting attributes, Too many links, /home/yasu/.emacs ---------------------------------------------------------------------- So it seems the source of the problem exists in not kernel but userland.
Hi Kimura-san! Thanks for debugging. That's very helpful. Could you try this on your problematic installation ? $ truss -s 500 -f emacs --eval '(kill-emacs)' 2>/tmp/emacs.err And attach the /tmp/emacs.err to this bug report, or you can investigate yourself by grep-ing for the error message in the file, and then checking to see if there are any failed syscalls around that, which can shed some light on this ? My guess is likely not, as you mention that it's a userspace problem. Thanks!
Could you also share the output of, from the problematic system: $ pkg info editors/emacs-devel |sed -n -e '/^Options/,/^[^[:space:]]/p' Or: $ make -C /usr/ports/editors/emacs-devel showconfig Thanks!
Hi Kimura-san! I think I figured it out. Could you please compile following program on problematic system: ======================= /* rlnkat2.c */ #include <sys/stat.h> #include <errno.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <string.h> #include <strings.h> #define BUFSIZE 1024 int main(int argc, char** argv) { int i,ret; char buffer[BUFSIZE]; struct stat st; int fd; for(i = 1; i < argc; i++) { bzero( buffer, sizeof( buffer )); fd = AT_FDCWD; ret = EINVAL; #ifdef O_PATH fprintf( stderr, "Trying openat(%s): ", argv[i]); ret = openat( fd, argv[i], O_PATH | O_CLOEXEC | O_NOFOLLOW, 0); if( -1 == ret ) { ret = errno; perror("openat"); } else { fprintf( stderr, "%d\n", ret ); if( 0 != fstat( ret, &st )) { ret = errno; fprintf( stderr, "fstat(%s): errno: %d, %s\n", argv[i], errno, strerror(errno)); } else { fd = ret; ret = 0; }; } #endif if( EINVAL == ret ) { ret = fstatat( fd, argv[i], &st, AT_SYMLINK_NOFOLLOW ); } if( -1 == ret ) { perror("fstatat"); continue; } if( S_ISLNK( st.st_mode )) { ret = readlinkat( fd, argv[i], buffer, sizeof( buffer )); if( -1 == ret ) { perror("readlinkat"); } else { fprintf(stderr, "%d. %s symlink to %s\n", i, argv[i], buffer ); } } else { fprintf( stderr, "%d. %s (is directory: %d)\n", i, argv[i], S_ISDIR( st.st_mode)); } } return 0; } ================= % cc -o rlnkat rlnkat.c % ./rlnkat .emacs .init-files/.emacs .init-files My guess is O_PATH is defined in 14-CURRENT[0], which enables openat(), which is passed a symlink as parameter with O_NOFOLLOW. ========== excerpt from open(2): [EMLINK] O_NOFOLLOW was specified and the target is a symbolic link. ========== So the culprit is openat but it only gets enabled/compiled on a system which has O_PATH defined in its headers (which only happened after that particular revision[0]). If this is indeed the case, then as per man page of open(2)[1] from GNU/Linux: ========= ELOOP Too many symbolic links were encountered in resolving pathname. ELOOP pathname was a symbolic link, and flags specified O_NOFOLLOW but not O_PATH. ========= it seems like a bug in FreeBSD implement, as GNU Emacs seems to be passing O_PATH along with O_NOFOLLOW which should not cause this EMLINK error. Anyways, this is all a speculation, so please let us know the output. And thank you for trying various things. References: [0] https://cgit.freebsd.org/src/commit/?id=8d9ed174f3afba5f114742447e622fc1173d4774 [1] https://www.man7.org/linux/man-pages/man2/open.2.html Good night!
(In reply to Ashish SHUKLA from comment #10) I got following result. ---------------------------------------------------------------------- yasu@rolling-vm-freebsd1[1064]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n249811-a36230f75e0: Sat Oct 2 01:34:30 JST 2021 rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1065]% make cc -O2 -pipe -c rlnkat.c -o rlnkat.o cc -o rlnkat rlnkat.o cc -O2 -pipe -c rlnkat2.c -o rlnkat2.o cc -o rlnkat2 rlnkat2.o yasu@rolling-vm-freebsd1[1066]% ls -ld ~/.emacs ~/.init-files ~/.init-files/.emacs lrwxr-xr-x 1 yasu user 29 10月 3 10:49 /home/yasu/.emacs@ -> /home/yasu/.init-files/.emacs drwxr-xr-x 7 yasu user 20 10月 2 13:23 /home/yasu/.init-files/ -rw-r--r-- 1 yasu user 4838 10月 2 13:23 /home/yasu/.init-files/.emacs yasu@rolling-vm-freebsd1[1067]% ./rlnkat2 ~/.emacs ~/.init-files ~/.init-files/.emacs Trying openat(/home/yasu/.emacs): 3 1. /home/yasu/.emacs symlink to /home/yasu/.init-files/.emacs Trying openat(/home/yasu/.init-files): 4 2. /home/yasu/.init-files (is directory: 1) Trying openat(/home/yasu/.init-files/.emacs): 5 3. /home/yasu/.init-files/.emacs (is directory: 0) yasu@rolling-vm-freebsd1[1068]% ----------------------------------------------------------------------
(In reply to Yasuhiro Kimura from comment #11) What if you run rlnkat on this system "main-n246034-e6ab1e365c" ? Thank you!
(In reply to Ashish SHUKLA from comment #8) Also were you able to try this `truss` ? As far as I can tell, there are two problems, 1) where `find-attributes` returned "Too many links" error (main-n246034-e6ab1e365c), and 2) where it returned nil (main-n249811-a36230f75e0). Thanks in advance
(In reply to Ashish SHUKLA from comment #12) ---------------------------------------------------------------------- yasu@rolling-vm-freebsd4[1005]% uname -a FreeBSD rolling-vm-freebsd4.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n246034-e6ab1e365c0: Tue Oct 5 04:34:51 JST 2021 rootz@rolling-vm-freebsd4.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd4[1006]% make cc -O2 -pipe -c rlnkat.c -o rlnkat.o cc -o rlnkat rlnkat.o cc -O2 -pipe -c rlnkat2.c -o rlnkat2.o cc -o rlnkat2 rlnkat2.o yasu@rolling-vm-freebsd4[1007]% ls -ld ~/.emacs ~/.init-files ~/.init-files/.emacs lrwxr-xr-x 1 yasu user 29 10月 3 10:49 /home/yasu/.emacs@ -> /home/yasu/.init-files/.emacs drwxr-xr-x 7 yasu user 20 10月 2 13:23 /home/yasu/.init-files/ -rw-r--r-- 1 yasu user 4838 10月 2 13:23 /home/yasu/.init-files/.emacs yasu@rolling-vm-freebsd4[1008]% ./rlnkat ~/.emacs ~/.init-files ~/.init-files/.emacs 1. /home/yasu/.emacs symlink to /home/yasu/.init-files/.emacs 2. /home/yasu/.init-files (is directory: 1) 3. /home/yasu/.init-files/.emacs (is directory: 0) yasu@rolling-vm-freebsd4[1009]% ----------------------------------------------------------------------
(In reply to Ashish SHUKLA from comment #13) Result of `truss -s 500 -f emacs --eval '(kill-emacs)' 2>/tmp/emacs.err` on main-n249811-a36230f75e0. https://www.utahime.org/FreeBSD/main-n249811-a36230f75e0.emacs.err And result of `pkg info editors/emacs-devel |sed -n -e '/^Options/,/^[^[:space:]]/p'` on main-n249811-a36230f75e0. ---------------------------------------------------------------------- yasu@rolling-vm-freebsd1[1038]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n249811-a36230f75e0: Sat Oct 2 01:34:30 JST 2021 rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1038]% pkg info editors/emacs-devel |sed -n -e '/^Options/,/^[^[:space:]]/p' Options : ACL : on GNUTLS : on JSON : on KQUEUE : on MAILUTILS : off MODULES : on NATIVECOMP : on SOURCES : on THREADS : on XML : on Shared Libs required: yasu@rolling-vm-freebsd1[1039]% ---------------------------------------------------------------------- But I confirmed the problem still happens if I disabled NATIVECOMP option.
(In reply to Yasuhiro Kimura from comment #15) Hi Kimura-san! Following excerpt from truss output looks interesting: --------- 3037: read(5,";;; -*- Mode: emacs-lisp -*-\n;;;\n;;; Startup file for GNU Emacs\n\n;;;\n;;; OS\M-g\M^R\M-0\M-e\M-"\M^C\M-c\M^A\M-.\M-f\M-$\M^\\M-e\M^G\M-:\n;;;\n(cond ((eq system-type 'gnu/linux)\n (setq utahime:os-name\n\t (substring (shell-command-to-stri 3037: lseek(5,0x0,SEEK_SET) = 0 (0x0) 3037: close(5) = 0 (0x0) 3037: openat(AT_FDCWD,"/home/yasu/.emacs",O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH,00) = 5 (0x5) 3037: fstat(5,{ mode=lrwxr-xr-x ,inode=471008,size=29,blksize=4096 }) = 0 (0x0) 3037: readlinkat(5,"",0x7fffffffd090,1024) ERR#2 'No such file or directory' 3037: close(5) = 0 (0x0) --------- Compared to following output on my GNU/Linux host: --------- openat(AT_FDCWD, ".emacs", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 3 newfstatat(3, "", {st_mode=S_IFLNK|0777, st_size=15, ...}, AT_EMPTY_PATH) = 0 readlinkat(3, "", ".emacs.d/.emacs", 1024) = 15 --------- --------- lrwxrwxrwx abbe users 15 B Thu Oct 7 08:09:27 2021 .emacs ⇒ .emacs.d/.emacs --------- Esp. the readlinkat() syscall invocation where it returns ENOENT (on FreeBSD), compared to GNU/Linux where it returns the symlink target. I'm trying to get access to a recent 14-CURRENT host, where I can verify this. It'll take me some time. Thank you for providing outputs so far. And thanks in advance for patience.
(In reply to Ashish SHUKLA from comment #16) It took for a while but `git bisect` finished. And according to it the problem happens with base 8d9ed174f3a or later. ---------------------------------------------------------------------- commit 8d9ed174f3a Author: Konstantin Belousov <kib@FreeBSD.org> Date: Thu Mar 18 19:41:47 2021 open(2): Implement O_PATH Reviewed by: markj Tested by: pho Discussed with: walker.aj325_gmail.com, wulf Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D29323 ---------------------------------------------------------------------- Is it consistent with the result of your investigation?
(In reply to Yasuhiro Kimura from comment #17) Hi Kimura-san! As I mentioned in comment #10, it's indeed that commit base 8d9ed174f3, which caused O_PATH pre-processor conditional block (in dired.c) to become active and take that path, and as readlinkat does not seem to exhibit same behaviour as GNU/Linux (which is what likely that Emacs code was implemented on), it breaks Emacs' assumption. I've yet to verify it myself due to lack of corresponding 14-CURRENT host, but your bisection confirms it. I'll get back to you with next steps. Thanks for your help so far.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5fb54d2fc845464ea809e6a1a69380693943cf51 commit 5fb54d2fc845464ea809e6a1a69380693943cf51 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2021-10-09 05:12:05 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2021-10-09 19:31:37 +0000 readlinkat(2): allow O_PATH fd PR: 258856 Reported by: ashish Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D32390 lib/libc/sys/open.2 | 5 +++-- sys/kern/vfs_syscalls.c | 4 ++-- 2 files changed, 5 insertions(+), 4 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=156db355733241fc1fd824fd8b1ce9f6f7f5f30a commit 156db355733241fc1fd824fd8b1ce9f6f7f5f30a Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2021-10-09 05:12:05 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2021-10-10 09:22:58 +0000 readlinkat(2): allow O_PATH fd PR: 258856 (cherry picked from commit 5fb54d2fc845464ea809e6a1a69380693943cf51) lib/libc/sys/open.2 | 5 +++-- sys/kern/vfs_syscalls.c | 4 ++-- 2 files changed, 5 insertions(+), 4 deletions(-)
Marking as closed, as it is not reproducible for me anymore after the proposed change. Please re-open it, if it's still not resolved for you.