Open Zjl37 opened 1 month ago
看起来是webkit那边的锅,而且不像是以后会fix的样子,这样xwidgets只好关掉了(
我今日(10月6日)在自己机子上手动构建了 aur/emacs-git,问题不能复现;
aur/emacs-git默认没有开xwidgets选项
又尝试用此仓库里 emacs-native-comp-git 原样的 PKGBUILD 构建,但 configure 阶段遇到错误 configure: error: xwidgets requested but WebKitGTK+ or WebKit framework not found.
因为开了xwidget
只有此一处不同的构建版本也不能复现此问题。
刚去试了一下,关了XWIDGETS之后emacs-git相关包都是可以build的
https://lists.nongnu.org/archive/html/bug-gnu-emacs/2023-09/msg02680.html
震惊了。
刚拉了 archlinuxcn 里今日的 emacs-native-comp-git 31.0.50.175109-1
版本(看了一眼 system-configuration-options
变量,确实没有了 xwidgets),问题仍能复现。
而我自己用现在的 PKGBUILD 刚刚编译的 emacs-native-comp-git
,同样是 175109,竟无此问题。我打的包上传到了网盘:https://wwtt.lanzn.com/iBo6C2bupggb(因为网盘不支持那个后缀名,又用zip包了一层),可以比一下有什么不一样。
正如我在彼 issue 中指出的,此错误根源于有问题的 emacs 版本在调用 package-buffer-info
-> …… -> package-read-from-string
会抛错,即使当前 buffer 的 .el
文件是书写格式规范的 elisp 库。这里的函数是关乎从 .el
文件头部的注释中提取一些 elisp 包管理器需要的包的元信息的,跟你引的 XWIDGETS 导致崩溃应该说是毫无关系的。我都从来没用过 XWIDGETS 有关功能。
得麻烦你深入地研究一下了。
用的是 这份 PKGBUILD,并且是 extra-x86_64-build 吗?
这里有archlinuxcn的buildlog 可以参考一下。
用的是 这份 PKGBUILD,并且是 extra-x86_64-build 吗?
是这份 PKGBUILD,但是没有用 extra-x86_64-build 脚本,而是直接在我的电脑上 makepkg -s
出来的。我待会试试 Building in a clean chroot(之前不知道)。
另外,有如下发现:
package-buffer-info
和 package-read-from-string
函数皆定义于 /usr/share/emacs/31.0.50/lisp/emacs-lisp/package.el.gz
。该文件内容在几个版本间从来没有变过。但是,在有问题的 emacs 版本中,把光标置于 package-read-from-string
的 defun 的结尾,eval-last-sexp
一下,那份 init.el
就能正常跑了,后续 emacs 也能不报错正常启动。把 init-directory 删到只剩 init.el
,启动又会出错。莫非 aot 出锅了?
忘记说了,上周 extra-x86_64-build 出来也无法复现此问题。Build log 我也看不明白。但是我觉得我已经非常努力确保构建过程干净且相同了。
所以还是希望麻烦你拨冗确认一下问题在你那边存不存在,现在步骤非常简单:
emacs -Q
M-x package-initialize
M-: (package-buffer-info)
或者直接一行命令:emacs --batch --eval '(print (progn (find-file "/usr/share/emacs/31.0.50/lisp/emacs-lisp/package.el.gz") (package-initialize) (package-buffer-info)))'
正常的话应该返回一个有一些信息的数据结构,但实际上会报错。
希望我说得够清楚🥺
lilac 打包时会复用缓存(~/.cache),是不是这儿的问题?
lilac 打包时会复用缓存(~/.cache),是不是这儿的问题?
不好说,因为我的 ~/.cache 里没有真正跟 emacs 有关的东西。但不排除可能是别的地方脏了——我不了解你们打包的流程,但我还有个强烈的疑惑:为什么之前 xwidgets 还开着时我没法构建,但你们的机器仍能每天不断的打包出来?是不是隐性地使用了打包机器上的某些东西?
另外,我发现我 pacman cache 里有许多过往软件包版本没删,其中最早有今年 4 月 14 日的 /var/cache/pacman/pkg/emacs-native-comp-pgtk-git-30.0.50.171720-1-x86_64.pkg.tar.zst
,该版竟能复现此问题,说明此问题已经存在很久了。
为什么之前 xwidgets 还开着时我没法构建,但你们的机器仍能每天不断的打包出来?是不是隐性地使用了打包机器上的某些东西?
自从9.22左右那个xwidgets break之后emacs那三个包就没有继续更新过,编译机上也没能继续构建,没有再"每天不断的打包出来"。这边历史记录上也能看到
我cleanup-package-files了一下,再看看新包吧。
我已经复现出来了,看起来是 native-comp 的问题,与 xwidget 无关。
(with-temp-buffer
(insert-file-contents "/home/condy/.emacs.d/elpa/lsp-mode-20241011.445/lsp-mode.el")
(package-buffer-info))
;; 根因其实是 package-read-from-string
(package-read-from-string "((emacs))")
首先可以以 lsp-mode.el 为例,看看有没有问题。我在 emacs-git 下测试是没有问题的,随后又安装了 archlinuxcn/emacs-native-comp-git 测试存在问题。
(defun package-read-from-string (str)
"Read a Lisp expression from STR.
Signal an error if the entire string was not used."
(pcase-let ((`(,expr . ,offset) (read-from-string str)))
(condition-case ()
;; The call to `ignore' suppresses a compiler warning.
(progn (ignore (read-from-string str offset))
(error "Can't read whole string"))
(end-of-file expr))))
然后我重新 C-x C-e 了一下 package-read-from-string
这个函数,确保它调用的不是 native-comp 的版本,此时正常。
随后即使强制它为 native-comp 函数,也无法复现了。
(native-compile 'package-read-from-string)
我比较了一下前后两个 native-comp 函数的二进制,似乎没有问题的那个二进制把流程会长许多,里面还有 symbol-value 之类的函数调用。
正确的二进制:
0000000000001120 <F7061636b6167652d726561642d66726f6d2d737472696e67_package_read_from_string_0>:
1120: 41 56 push %r14
1122: 55 push %rbp
1123: 53 push %rbx
1124: 48 83 ec 40 sub $0x40,%rsp
1128: 48 8b 1d 99 2e 00 00 mov 0x2e99(%rip),%rbx # 3fc8 <d_reloc@@Base-0x338>
112f: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax
1136: 00 00
1138: 48 89 44 24 38 mov %rax,0x38(%rsp)
113d: 48 8b 05 8c 2e 00 00 mov 0x2e8c(%rip),%rax # 3fd0 <freloc_link_table@@Base-0x3b8>
1144: 48 8b 7b 08 mov 0x8(%rbx),%rdi
1148: 48 8b 28 mov (%rax),%rbp
114b: 48 8b 03 mov (%rbx),%rax
114e: 48 89 44 24 10 mov %rax,0x10(%rsp)
1153: ff 95 18 29 00 00 call *0x2918(%rbp) ; Fsymbol_value str
1159: 48 8d 74 24 10 lea 0x10(%rsp),%rsi
115e: bf 02 00 00 00 mov $0x2,%edi
1163: 48 89 44 24 18 mov %rax,0x18(%rsp)
1168: ff 95 c8 1c 00 00 call *0x1cc8(%rbp) ; Ffuncall -> (read-from-string str)
116e: 48 8b 7b 10 mov 0x10(%rbx),%rdi
1172: 66 48 0f 6e c0 movq %rax,%xmm0
1177: 48 89 c6 mov %rax,%rsi
117a: 66 0f 6c c0 punpcklqdq %xmm0,%xmm0
117e: 0f 29 44 24 10 movaps %xmm0,0x10(%rsp)
1183: ff 55 60 call *0x60(%rbp) ; specbind -> to temporary variable
1186: 48 8b 7c 24 10 mov 0x10(%rsp),%rdi
118b: ff 95 b0 29 00 00 call *0x29b0(%rbp) ;car
1191: 48 8b 7b 18 mov 0x18(%rbx),%rdi
1195: 48 89 c6 mov %rax,%rsi
1198: 48 89 44 24 10 mov %rax,0x10(%rsp)
119d: ff 55 60 call *0x60(%rbp) ; specbind -> expr
11a0: 48 8b 7b 10 mov 0x10(%rbx),%rdi
11a4: ff 95 18 29 00 00 call *0x2918(%rbp) ; Fsymbol_value
11aa: 48 89 44 24 10 mov %rax,0x10(%rsp)
11af: 48 89 c7 mov %rax,%rdi
11b2: ff 95 a8 29 00 00 call *0x29a8(%rbp) ; cdr
11b8: 48 8b 7b 20 mov 0x20(%rbx),%rdi
11bc: 48 89 c6 mov %rax,%rsi
11bf: 48 89 44 24 10 mov %rax,0x10(%rsp)
11c4: ff 55 60 call *0x60(%rbp) ;specbind -> offset
11c7: 48 8b 7b 18 mov 0x18(%rbx),%rdi
11cb: ff 95 18 29 00 00 call *0x2918(%rbp) ;Fsymbol_value expr
11d1: 48 8b 7b 20 mov 0x20(%rbx),%rdi
11d5: 48 89 44 24 10 mov %rax,0x10(%rsp)
11da: ff 95 18 29 00 00 call *0x2918(%rbp) ;Fsymbol_value offset
11e0: 48 8b 7b 28 mov 0x28(%rbx),%rdi
11e4: 48 89 44 24 18 mov %rax,0x18(%rsp)
11e9: 48 89 c6 mov %rax,%rsi
11ec: ff 55 60 call *0x60(%rbp) ;specbind -> offset
11ef: 48 8b 7b 30 mov 0x30(%rbx),%rdi
11f3: 48 8b 74 24 10 mov 0x10(%rsp),%rsi
11f8: ff 55 60 call *0x60(%rbp) ;specbind
11fb: 48 8b 7b 38 mov 0x38(%rbx),%rdi
11ff: 48 89 6c 24 08 mov %rbp,0x8(%rsp)
1204: be 01 00 00 00 mov $0x1,%esi
1209: 48 89 7c 24 10 mov %rdi,0x10(%rsp)
120e: ff 55 18 call *0x18(%rbp) ;push_handler (condition-case)
1211: 48 8d 78 40 lea 0x40(%rax),%rdi
1215: e8 26 fe ff ff call 1040 <_setjmp@plt>
121a: 48 8b 6c 24 08 mov 0x8(%rsp),%rbp
121f: 48 8b 95 18 29 00 00 mov 0x2918(%rbp),%rdx
1226: 85 c0 test %eax,%eax
1228: 74 66 je 1290 <F7061636b6167652d726561642d66726f6d2d737472696e67_package_read_from_string_0+0x170>
122a: 48 8b 05 87 2d 00 00 mov 0x2d87(%rip),%rax # 3fb8 <current_thread_reloc@@Base-0x328>
1231: 48 8b 00 mov (%rax),%rax
1234: 48 8b 08 mov (%rax),%rcx
1237: 48 8b 41 60 mov 0x60(%rcx),%rax
123b: 48 8b 70 20 mov 0x20(%rax),%rsi
123f: 48 8b 40 18 mov 0x18(%rax),%rax
1243: 48 89 44 24 10 mov %rax,0x10(%rsp)
1248: 48 8b 05 79 2d 00 00 mov 0x2d79(%rip),%rax # 3fc8 <d_reloc@@Base-0x338>
124f: 48 89 71 60 mov %rsi,0x60(%rcx)
1253: 48 8b 78 30 mov 0x30(%rax),%rdi
1257: ff d2 call *%rdx ;Fsymbol_value
1259: 48 89 44 24 10 mov %rax,0x10(%rsp)
125e: 48 8b 44 24 08 mov 0x8(%rsp),%rax
1263: bf 16 00 00 00 mov $0x16,%edi
1268: ff 50 28 call *0x28(%rax) ;helper_unbind_n
126b: 48 8b 44 24 10 mov 0x10(%rsp),%rax
1270: 48 8b 54 24 38 mov 0x38(%rsp),%rdx
1275: 64 48 2b 14 25 28 00 sub %fs:0x28,%rdx
127c: 00 00
127e: 0f 85 8b 00 00 00 jne 130f <F7061636b6167652d726561642d66726f6d2d737472696e67_package_read_from_string_0+0x1ef>
1284: 48 83 c4 40 add $0x40,%rsp
1288: 5b pop %rbx
1289: 5d pop %rbp
128a: 41 5e pop %r14
128c: c3 ret
128d: 0f 1f 00 nopl (%rax)
1290: 48 8b 1d 31 2d 00 00 mov 0x2d31(%rip),%rbx # 3fc8 <d_reloc@@Base-0x338>
1297: 48 8d 6c 24 10 lea 0x10(%rsp),%rbp
129c: 48 8b 03 mov (%rbx),%rax
129f: 48 8b 7b 08 mov 0x8(%rbx),%rdi
12a3: 48 89 44 24 10 mov %rax,0x10(%rsp)
12a8: ff d2 call *%rdx ; Fsymbol_value str
12aa: 4c 8b 74 24 08 mov 0x8(%rsp),%r14
12af: 48 8b 7b 28 mov 0x28(%rbx),%rdi
12b3: 48 89 44 24 18 mov %rax,0x18(%rsp)
12b8: 41 ff 96 18 29 00 00 call *0x2918(%r14) ;Fsymbol_value offset
12bf: 48 89 ee mov %rbp,%rsi
12c2: bf 03 00 00 00 mov $0x3,%edi
12c7: 48 89 44 24 20 mov %rax,0x20(%rsp)
12cc: 41 ff 96 c8 1c 00 00 call *0x1cc8(%r14) ;Ffuncall (read-from-string str offset) ; end-of-file
12d3: f3 0f 6f 43 48 movdqu 0x48(%rbx),%xmm0
12d8: 48 89 ee mov %rbp,%rsi
12db: bf 02 00 00 00 mov $0x2,%edi
12e0: 0f 29 44 24 10 movaps %xmm0,0x10(%rsp)
12e5: 41 ff 96 c8 1c 00 00 call *0x1cc8(%r14) ;Ffuncall ignore
12ec: 48 89 44 24 10 mov %rax,0x10(%rsp)
12f1: 48 8b 05 c0 2c 00 00 mov 0x2cc0(%rip),%rax # 3fb8 <current_thread_reloc@@Base-0x328>
12f8: 48 8b 00 mov (%rax),%rax
12fb: 48 8b 00 mov (%rax),%rax
12fe: 48 8b 50 60 mov 0x60(%rax),%rdx
1302: 48 8b 52 20 mov 0x20(%rdx),%rdx
1306: 48 89 50 60 mov %rdx,0x60(%rax)
130a: e9 4f ff ff ff jmp 125e <F7061636b6167652d726561642d66726f6d2d737472696e67_package_read_from_string_0+0x13e>
130f: e8 1c fd ff ff call 1030 <__stack_chk_fail@plt>
1314: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1)
131b: 00 00 00 00
131f: 90 nop
错误的二进制:
0000000000012590 <F7061636b6167652d726561642d66726f6d2d737472696e67_package_read_from_string_0>:
12590: 41 56 push %r14
12592: 66 48 0f 6e c7 movq %rdi,%xmm0
12597: 53 push %rbx
12598: 66 0f 6f c8 movdqa %xmm0,%xmm1
1259c: 48 83 ec 58 sub $0x58,%rsp
125a0: 48 8b 1d 19 8a 02 00 mov 0x28a19(%rip),%rbx # 3afc0 <d_reloc@@Base-0x25680>
125a7: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax
125ae: 00 00
125b0: 48 89 44 24 48 mov %rax,0x48(%rsp)
125b5: 48 8b 05 0c 8a 02 00 mov 0x28a0c(%rip),%rax # 3afc8 <freloc_link_table@@Base-0x27a18>
125bc: 48 8d 74 24 18 lea 0x18(%rsp),%rsi
125c1: 48 89 7c 24 20 mov %rdi,0x20(%rsp)
125c6: bf 02 00 00 00 mov $0x2,%edi
125cb: 0f 16 8b 98 09 00 00 movhps 0x998(%rbx),%xmm1
125d2: 0f 29 4c 24 10 movaps %xmm1,0x10(%rsp)
125d7: 4c 8b 30 mov (%rax),%r14
125da: 4c 89 74 24 08 mov %r14,0x8(%rsp)
125df: 41 ff 96 c8 1c 00 00 call *0x1cc8(%r14) ; Ffuncall
125e6: 66 48 0f 6e c0 movq %rax,%xmm0
125eb: 48 89 c7 mov %rax,%rdi
125ee: 66 0f 6c c0 punpcklqdq %xmm0,%xmm0
125f2: 0f 11 44 24 18 movups %xmm0,0x18(%rsp)
125f7: 41 ff 96 b0 29 00 00 call *0x29b0(%r14) ; car
125fe: 48 8b 7c 24 18 mov 0x18(%rsp),%rdi
12603: 66 48 0f 6e c0 movq %rax,%xmm0
12608: 0f 16 44 24 18 movhps 0x18(%rsp),%xmm0
1260d: 0f 29 44 24 20 movaps %xmm0,0x20(%rsp)
12612: 41 ff 96 a8 29 00 00 call *0x29a8(%r14) ; cdr
12619: 48 8b bb a0 09 00 00 mov 0x9a0(%rbx),%rdi
12620: be 01 00 00 00 mov $0x1,%esi
12625: 66 48 0f 6e c0 movq %rax,%xmm0
1262a: 66 48 0f 6e d7 movq %rdi,%xmm2
1262f: 66 0f 6c c2 punpcklqdq %xmm2,%xmm0
12633: 0f 11 44 24 28 movups %xmm0,0x28(%rsp)
12638: 41 ff 56 18 call *0x18(%r14) ; push_handler (condition-case)
1263c: 48 8d 78 40 lea 0x40(%rax),%rdi
12640: e8 fb 69 ff ff call 9040 <_setjmp@plt>
12645: 85 c0 test %eax,%eax
12647: 74 37 je 12680 <F7061636b6167652d726561642d66726f6d2d737472696e67_package_read_from_string_0+0xf0>
12649: 48 8b 05 60 89 02 00 mov 0x28960(%rip),%rax # 3afb0 <current_thread_reloc@@Base-0x25670>
12650: 48 8b 00 mov (%rax),%rax
12653: 48 8b 00 mov (%rax),%rax
12656: 48 8b 50 60 mov 0x60(%rax),%rdx
1265a: 48 8b 52 20 mov 0x20(%rdx),%rdx
1265e: 48 89 50 60 mov %rdx,0x60(%rax)
12662: 48 8b 44 24 20 mov 0x20(%rsp),%rax
12667: 48 8b 54 24 48 mov 0x48(%rsp),%rdx
1266c: 64 48 2b 14 25 28 00 sub %fs:0x28,%rdx
12673: 00 00
12675: 75 58 jne 126cf <F7061636b6167652d726561642d66726f6d2d737472696e67_package_read_from_string_0+0x13f>
12677: 48 83 c4 58 add $0x58,%rsp
1267b: 5b pop %rbx
1267c: 41 5e pop %r14
1267e: c3 ret
1267f: 90 nop
12680: 48 8b 05 39 89 02 00 mov 0x28939(%rip),%rax # 3afc0 <d_reloc@@Base-0x25680>
12687: 48 8d 74 24 30 lea 0x30(%rsp),%rsi
1268c: bf 02 00 00 00 mov $0x2,%edi
12691: 48 8b 90 30 03 00 00 mov 0x330(%rax),%rdx
12698: 48 8b 80 a8 09 00 00 mov 0x9a8(%rax),%rax
1269f: 48 89 44 24 38 mov %rax,0x38(%rsp)
126a4: 48 8b 44 24 08 mov 0x8(%rsp),%rax
126a9: 48 89 54 24 30 mov %rdx,0x30(%rsp)
126ae: ff 90 c8 1c 00 00 call *0x1cc8(%rax) ; Ffuncall
126b4: 48 8b 15 f5 88 02 00 mov 0x288f5(%rip),%rdx # 3afb0 <current_thread_reloc@@Base-0x25670>
126bb: 48 8b 12 mov (%rdx),%rdx
126be: 48 8b 12 mov (%rdx),%rdx
126c1: 48 8b 4a 60 mov 0x60(%rdx),%rcx
126c5: 48 8b 49 20 mov 0x20(%rcx),%rcx
126c9: 48 89 4a 60 mov %rcx,0x60(%rdx)
126cd: eb 98 jmp 12667 <F7061636b6167652d726561642d66726f6d2d737472696e67_package_read_from_string_0+0xd7>
126cf: e8 5c 69 ff ff call 9030 <__stack_chk_fail@plt>
126d4: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1)
126db: 00 00 00 00
126df: 90 nop
可以看到在错误的情况下,流程简化了许多,所以我觉得是 native-comp (AOT) 的问题。因为现在确定出问题的文件是在 AOT 阶段就构建的,所以怀疑是 AOT 阶段生成 eln 文件时就出错了。
我建议修改一下 PKGBUILD, 使用 make bootstrap 而不是 make 以确保没有缓存的影响。或者在构建前将 native-lisp 目录删除,以保证 emacs 每次都会重新生成新的 eln 文件。
自从9.22左右那个xwidgets break之后emacs那三个包就没有继续更新过
好吧,那可能是我印象记错了。
我cleanup-package-files了一下,再看看新包吧。
今日的 31.0.50.175227-1 版仍存在问题。
@condy0919 非常感谢,我也十分怀疑 AOT native comp,但不会举证。想请教一下 native compile 出来的二进制位置在哪,如何查看。
@condy0919 非常感谢,我也十分怀疑 AOT native comp,但不会举证。想请教一下 native compile 出来的二进制位置在哪,如何查看。
(cl-letf (((symbol-function 'delete-file) 'ignore))
(native-compile 'package-read-from-string))
然后在 /tmp/ 里查看 freefn 开头的 eln 文件, objdump -d freefn-xxxyyyzzz.eln
默认 AOT 是在 /usr/..../native-lisp/ 中, 也可以直接 M-x disass RET package-read-from-string RET 直接查看它的汇编。
近日的包,问题仍没有消失。
@ykelvis 请问你所说的 cleanup-package-files 是做什么的?能否更详细描述下你们机器打包的流程和环境?
或者,能否按 condy 所说的,以 make bootstrap 打一次包看看效果?
如果诚是由原生编译引入的行为差异,那谁知道还有没有其他函数的二进制与elisp代码原意不相符合?这样想也太可怕了。
cleanup-package-files 是清除打包目录(PKGBUILD 所在目录)的缓存文件用的。另外 lilac 打包环境中的 ~/.cache 会被保留并且是共享的。
换成make bootstrap
了, @Zjl37 试试看
很奇怪,还是有问题。
现在好像没啥继续排查的思路了😕
很奇怪,还是有问题。
现在好像没啥继续排查的思路了😕
要不你去邮件列表问问?
问题类型 / Type of issues
受影响的软件包 / Affected packages
emacs-native-comp-git
emacs-native-comp-pgtk-git
我在使用 archlinuxcn 分发的
emacs-native-comp-pgtk-git
时遇到了此问题:https://github.com/quelpa/quelpa/issues/255 ,其根本原因还没弄清楚,但那边建议我先尝试用稳定版本的 emacs 看能不能复现,结果现在排查发现:extra/emacs-nativecomp 29.4-2
,以及今日的archlinuxcn/emacs-git 31.0.50.……
无此问题。archlinuxcn/emacs-native-comp-pgtk-git 31.0.50.……
及archlinuxcn/emacs-native-comp-git 31.0.50.……
能复现此问题。aur/emacs-git
,问题不能复现;又尝试用此仓库里emacs-native-comp-git
原样的 PKGBUILD 构建,但 configure 阶段遇到错误configure: error: xwidgets requested but WebKitGTK+ or WebKit framework not found.
,这个错我一时半会不知道怎么解决,就先把 PKGBUILD 中的XWIDGETS="YES"
关闭了,只有此一处不同的构建版本也不能复现此问题。上述复现的尝试都是在干净的 archlinux 容器镜像中做的。
考虑到 XWIDGETS 功能与我报的问题极不相关,我暂且认为是上游 bug 的可能性较小,而极度怀疑 archlinuxcn 打的包出了一些小锅。没办法了,来这里求助,恳请 archlinuxcn 社区里的 emacs 道友和几个有关包的维护者,抽空点开我原 issue 看一眼,帮忙复现一下问题,看看是怎么个回事。🥺🙏麻烦各位了。