Author: netcasper

Stack overflow in regexp matcher

1 Comment

在Emacs里面使用gdb-many-windows调试，非常方便。但是有时候碰到复杂的局部变量，gdb-mi会无法显示，并报错：Stack overflow in regexp matcher。

不能显示局部变量问题不大，大不了手工使用p命令。问题是之后gdb-mi的状态就乱掉了，无法继续调试，非常烦人。

终于，使用下面的patch，一切都平静了……

diff --git a/lisp/progmodes/gdb-mi.el b/lisp/progmodes/gdb-mi.el
index 27846ed..d147b82 100644
--- a/lisp/progmodes/gdb-mi.el
+++ b/lisp/progmodes/gdb-mi.el
@@ -4022,7 +4022,7 @@ member."
 ;; Don't display values of arrays or structures.
 ;; These can be expanded using gud-watch.
 (defun gdb-locals-handler-custom ()
-  (let ((locals-list (bindat-get-field (gdb-json-partial-output) 'locals))
+  (let ((locals-list (bindat-get-field (ignore-errors (gdb-json-partial-output)) 'locals))
         (table (make-gdb-table)))
     (dolist (local locals-list)
       (let ((name (bindat-get-field local 'name))

Backup GMail

Leave a comment

尝试使用courier-imap和imapsync备份GMail的All Mail文件夹，到了一定阶段，mutt登录总是失败，报内存不足的错误。后来检查imapsync的log，发现也出现无法分配内存的错误。于是上网搜，发现docker并没有对内存进行任何限制。那问题出在哪里呢？

原来是courier-imap在限制内存使用，以下是一段在/etc/courier-imap/imapd里面关于参数IMAP_ULIMITD的注释。

The default value of 65536 sets a very generous limit of 64 megabytes, which should be more than plenty for anyone.

… It is theoretically possible that obscenely huge folders will also result in the server running out of memory when doing server-side sorting (by my calculations you have to have at least 100,000 messages in a single folder, for that to happen)

在出现问题的时候All Mail文件夹里已经有31万多封邮件了，全部备份完毕的时候有41万多。于是将限额增加到1G，同时将imapsync timout时间从2分钟增加到10分钟，终于备份了完整的All Mail。