From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: pure-fns in byte-opt.el Date: Thu, 27 Jul 2017 20:06:18 +0300 Message-ID: <83y3r94xo5.fsf@gnu.org> References: <20170725020650.GA12601@holos.localdomain> <20170726010000.GA14292@holos.localdomain> <83o9s75kus.fsf@gnu.org> <20170727023608.GA1895@holos.localdomain> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1501175219 31664 195.159.176.226 (27 Jul 2017 17:06:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Jul 2017 17:06:59 +0000 (UTC) Cc: schwab@suse.de, emacs-devel@gnu.org To: Mark Oteiza Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 27 19:06:55 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1damFM-0007ga-7t for ged-emacs-devel@m.gmane.org; Thu, 27 Jul 2017 19:06:48 +0200 Original-Received: from localhost ([::1]:44084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1damFS-00026l-3t for ged-emacs-devel@m.gmane.org; Thu, 27 Jul 2017 13:06:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33009) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1damFL-00026g-KB for emacs-devel@gnu.org; Thu, 27 Jul 2017 13:06:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1damFD-0006wQ-8i for emacs-devel@gnu.org; Thu, 27 Jul 2017 13:06:43 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1damFD-0006wG-5z; Thu, 27 Jul 2017 13:06:39 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2429 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1damFB-00059r-Ep; Thu, 27 Jul 2017 13:06:38 -0400 In-reply-to: <20170727023608.GA1895@holos.localdomain> (message from Mark Oteiza on Wed, 26 Jul 2017 22:36:08 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217082 Archived-At: > Date: Wed, 26 Jul 2017 22:36:08 -0400 > From: Mark Oteiza > Cc: schwab@suse.de, emacs-devel@gnu.org > > >If you could run the offending command under a debugger and show both > >C-level and Lisp-level backtrace from the error, maybe we could become > >wiser. (Let me know if you need help in staging the experiment and/or > >collecting the data after you catch the error.) > > Here is the point during the build the error happens: > > "../../src/bootstrap-emacs" -batch --no-site-file --no-site-lisp -L . -l > unidata-gen \ > -f unidata-gen-file ../../lisp/international/uni-decomposition.el . > Loading macroexp.elc... > Wrong type argument: listp, "щай" > > I set a breakpoint at wrong_type_argument > > Thread 1 "bootstrap-emacs" hit Breakpoint 4, wrong_type_argument ( > predicate=XIL(0x8550), value=XIL(0x3dee414)) at data.c:154 > 154 xsignal2 (Qwrong_type_argument, predicate, value); > (gdb) xbacktrace > "unidata-gen-table-word-list" (0xffffb690) > "unidata-gen-table-decomposition" (0xffffbb20) > "unidata-gen-file" (0xffffc108) > "funcall" (0xffffc100) > "if" (0xffffc2c0) > "cond" (0xffffc430) > "let*" (0xffffc5d0) > "while" (0xffffc760) > "let*" (0xffffc900) > "progn" (0xffffca30) > "if" (0xffffcb70) > "let" (0xffffcd50) > "let" (0xffffcf30) > "command-line-1" (0xffffd0b0) > "command-line" (0xffffd300) > "unwind-protect" (0xffffd4f0) > "let" (0xffffd6d0) > "if" (0xffffd840) > "normal-top-level" (0xffffd9c0) > > I would need help with digging deeper. Is this still relevant, i.e. do you still want to understand the details of the problem? If so, please show the C-level backtrace (the result of the "bt" command), and I will try to tell you where to look for those details. Thanks.