GNU bug report logs - #30788
27.0.50; Getting 'char-displayable-p: Invalid hash table rehash size: 1.0' when starting emacs -Q

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30788 in the body.
You can then email your comments to 30788 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mats Lidell <mats.lidell <at> cag.se>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Getting 'char-displayable-p: Invalid hash table rehash size:
 1.0' when starting emacs -Q
Date: Mon, 12 Mar 2018 23:12:18 +0100

[Message part 1 (text/plain, inline)]

Hi,

Getting the error message 'char-displayable-p: Invalid hash table rehash
size: 1.0' when starting emacs -Q.

If started with no window system ' emacs -nw' the problems does not
occure. (This email is prepared from that state.)

Older version of emacs ie 26.0.50 shows the same behavior on the same
system. Problem occured after upgrade of the OS and not after rebuild of
emacs. The problems remains when rebuilding emacs.

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
of 2018-03-11 built on barnacle
Repository revision: 0965d94ca426765382f366bf48f88ba5f9500afd
System Description: Gentoo/Linux

Configured using:
'configure --prefix=/home/matsl --without-pop --with-mailutils'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY ACL GNUTLS
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 THREADS
LIBSYSTEMD LCMS2

Important settings:
value of $LC_MONETARY: sv_SE.UTF-8
value of $LC_NUMERIC: sv_SE.UTF-8
value of $LC_TIME: sv_SE.UTF-8
value of $LANG: sv_SE.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
treemacs-git-mode: extended
global-company-mode: t
company-mode: t
helm-mode: t
helm-autoresize-mode: t
desktop-save-mode: t
dired-omit-mode: t
diff-auto-refine-mode: t
magit-auto-revert-mode: t
global-git-commit-mode: t
savehist-mode: t
global-undo-tree-mode: t
delete-selection-mode: t
show-paren-mode: t
save-place-mode: t
display-time-mode: t
async-bytecomp-package-mode: t
shell-dirtrack-mode: t
cl-old-struct-compat-mode: t
tooltip-mode: t
global-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
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
size-indication-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t

Load-path shadows:
/home/matsl/src/hyperbole/hyrolo hides ~/.emacs.d/elisp/etc/hyrolo

Features:
(shadow sort bbdb-message mailalias hsmail mail-extr emacsbug winner
eieio-opt speedbar sb-image ezimage dframe help-fns radix-tree thingatpt
helm-command helm-elisp helm-eval edebug helm-info term/xterm xterm
treemacs-mode treemacs-persist treemacs-interface
treemacs-mouse-interface treemacs-tag-follow-mode treemacs-follow-mode
treemacs-filewatch-mode treemacs-tags treemacs-faces
treemacs-branch-creation treemacs-async treemacs-visuals imenu
treemacs-structure treemacs-impl treemacs-macros treemacs-customization
pfuture ace-window avy ht f magit-bookmark bookmark pp hl-line hydra lv
s vc-dispatcher elec-pair vc-git autoinsert python tramp-sh dired-aux
company-oddmuse company-keywords company-etags etags xref project
company-gtags company-dabbrev-code company-dabbrev company-files
company-capf company-cmake company-xcode company-clang company-semantic
company-eclim company-template company-bbdb company pcase helm-mode
helm-files helm-buffers helm-tags helm-locate helm-grep helm-regexp
helm-utils helm-help helm-types helm-config helm-easymenu helm
helm-source eieio-compat helm-multi-match helm-lib site-gentoo
hib-ashell ashell desktop frameset dmacro bbdb-mua bbdb-com smtpmail
sendmail dired-x solar cal-dst holidays hol-loaddefs vc-hg appt
diary-lib diary-loaddefs org-agenda org-install calendar-swe
magit-obsolete magit-blame magit-stash magit-bisect magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-collab ghub let-alist
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log magit-diff smerge-mode diff-mode magit-core
magit-autorevert autorevert filenotify magit-process magit-margin
magit-mode git-commit magit-git magit-section magit-utils crm
magit-popup log-edit message rfc822 mml mml-sec epa derived gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mailabbrev mail-utils
gmm-utils mailheader pcvs-util add-log with-editor cl-extra help-mode
server dash savehist hyperbole hinit hibtypes hib-doc-id hsys-www klink
subr-x hib-kbd hib-social hib-debbugs hsys-org org-element avl-tree
generator org org-macro org-footnote org-pcomplete org-list org-faces
org-entities org-version ob-emacs-lisp ob ob-tangle org-src ob-ref
ob-lob ob-table ob-keys ob-exp ob-comint ob-core ob-eval org-compat
org-macs org-loaddefs find-func hactypes hui-mini hui hui-menu
hyrolo-menu hyrolo google-contacts xml url-cache google-oauth oauth2
warnings url-http tls gnutls url url-proxy url-privacy url-expand
url-methods url-history mailcap url-auth mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr url-cookie url-domsuf url-util
url-gw nsm rmc puny plstore epg bbdb bbdb-site timezone hmail hui-jmenu
noutline outline easy-mmode hmouse-sh hui-mouse hui-window pulse
hycontrol hmouse-key hargs hypb locate dired dired-loaddefs hmouse-drv
hsettings hui-em-but hbut hact hpath hhist hbdata htz cal-julian
cal-menu calendar cal-loaddefs hbmap hmoccur browse-url hui-select hvar
set hversion hload-path hyperbole-autoloads kotl-autoloads undo-tree
diff edmacro kmacro iso-transl delsel time-date matsl-theme paren
saveplace time async-bytecomp async cus-start cus-load tramp trampver
tramp-compat tramp-loaddefs ucs-normalize shell pcomplete comint
ansi-color ring parse-time format-spec advice mule-util finder-inf info
package easymenu epg-config url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json map url-vars
seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib 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 lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 478110 44903)
(symbols 48 45447 2)
(miscs 40 237 624)
(strings 32 120967 5885)
(string-bytes 1 3976593)
(vectors 16 71645)
(vector-slots 8 1092043 22456)
(floats 8 606 665)
(intervals 56 4699 408)
(buffers 992 34))

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mats Lidell <mats.lidell <at> cag.se>
Cc: 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Tue, 13 Mar 2018 05:44:01 +0200

> From: Mats Lidell <mats.lidell <at> cag.se>
> Date: Mon, 12 Mar 2018 23:12:18 +0100
> 
> Getting the error message 'char-displayable-p: Invalid hash table rehash
> size: 1.0' when starting emacs -Q.

Can you show a full recipe, including the character, and a Lisp
backtrace?  FWIW, I cannot reproduce this on my system.

Thanks.

Message #11 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: 30788 <at> debbugs.gnu.org
Subject: Re: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size:
 1.0' when starting emacs -Q
Date: Tue, 13 Mar 2018 11:14:18 +0100

Downstream bug: https://bugs.gentoo.org/650332

Message #14 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Tue, 13 Mar 2018 18:14:54 +0200

> Date: Tue, 13 Mar 2018 11:14:18 +0100
> From: Ulrich Mueller <ulm <at> gentoo.org>
> 
> Downstream bug: https://bugs.gentoo.org/650332

Can someone who can reproduce this please post a backtrace?

Message #17 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Mats Lidell <mats.lidell <at> cag.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ulrich Mueller <ulm <at> gentoo.org>, 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Tue, 13 Mar 2018 18:42:27 +0100

> Eli Zaretskii writes:
> > Date: Tue, 13 Mar 2018 11:14:18 +0100
> > From: Ulrich Mueller <ulm <at> gentoo.org>
> > 
> > Downstream bug: https://bugs.gentoo.org/650332
>
> Can someone who can reproduce this please post a backtrace?

I'm sorry Eli, I'm afraid I can't do that! (Or setting the pun aside lack the
skills or have a too broken emacs ...) Please advice what I should do.

What I have tried:

 - On starting emacs -Q I immediately get the message in the minibuffer.

 - If I then try M-x debug-on-entry RET I don't get the chance to enter what
   function to debug. In the message buffer I get: 'autoload-do-load: Invalid
   hash table rehash size: 1.0'

 - If I enter '(list-packages)' in *scratch* buffer and evaluate it I get:
   'debug: Invalid hash table rehash size: 1.0'

 - Starting with emacs --debug-init makes no difference. Same message. Nothing else.

The reason I try with list-packages above is that I first thought it could be
related to some bad package so I found that that command could trigger the
problem as well.

Good news though. Down grading to fontconfig version fontconfig-2.12.6 clears
the issue.

Message #20 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mats Lidell <mats.lidell <at> cag.se>
Cc: ulm <at> gentoo.org, 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Tue, 13 Mar 2018 20:08:15 +0200

> From: Mats Lidell <mats.lidell <at> cag.se>
> Cc: Ulrich Mueller <ulm <at> gentoo.org>,  <30788 <at> debbugs.gnu.org>
> Date: Tue, 13 Mar 2018 18:42:27 +0100
> 
> > Eli Zaretskii writes:
> > > Date: Tue, 13 Mar 2018 11:14:18 +0100
> > > From: Ulrich Mueller <ulm <at> gentoo.org>
> > > 
> > > Downstream bug: https://bugs.gentoo.org/650332
> >
> > Can someone who can reproduce this please post a backtrace?
> 
> I'm sorry Eli, I'm afraid I can't do that! (Or setting the pun aside lack the
> skills or have a too broken emacs ...) Please advice what I should do.

Start Emacs under GDB, put a breakpoint in Fmake_hash_table, where it
signals this error (line 4530 of fns.c in today's master), then run
Emacs with "run -Q", and when the breakpoint breaks, type "xbacktrace"
at the GDB prompt, and post the results here.

(If "xbacktrace" doesn't work, type "source /path/to/src/.gdbinit" and
try again.)

TIA

Message #23 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ulm <at> gentoo.org, 30788 <at> debbugs.gnu.org, Mats Lidell <mats.lidell <at> cag.se>
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Tue, 13 Mar 2018 19:58:13 +0100

>>>>> On Tue, 13 Mar 2018, Eli Zaretskii wrote:

> Start Emacs under GDB, put a breakpoint in Fmake_hash_table, where it
> signals this error (line 4530 of fns.c in today's master), then run
> Emacs with "run -Q", and when the breakpoint breaks, type "xbacktrace"
> at the GDB prompt, and post the results here.

This is what I get with this recipe for the current tip of the master
branch (commit 06911714ef):

Thread 1 "emacs-27-vcs" hit Breakpoint 3, Fmake_hash_table (
    nargs=nargs <at> entry=10, args=args <at> entry=0x7ffffffe3670) at
    fns.c:4530
4530        signal_error ("Invalid hash table rehash size", args[i]);
(gdb) xbacktrace
"read" (0xffffc188)
"char-displayable-p" (0xffffc508)
"startup--setup-quote-display" (0xffffc820)
"command-line" (0xffffd0b8)
"normal-top-level" (0xffffd460)

Note that the error occurs with LC_ALL=de_DE.UTF-8, whereas with
LC_ALL=C or even LC_ALL=en_US.UTF-8 all seems to be fine.


With Emacs 25.3 I get the following, after typing (list-packages) C-j
in the scratch buffer (again, with de_DE.UTF-8 locale):

Debugger entered--Lisp error: (error "Invalid hash table rehash size" 1.0)
  read(#<buffer  *load*>)
  eval-buffer(#<buffer  *load*> nil "/usr/share/emacs/25.3/lisp/finder-inf.el" nil t)  ; Reading at buffer position 39098
  load-with-code-conversion("/usr/share/emacs/25.3/lisp/finder-inf.el" "/usr/share/emacs/25.3/lisp/finder-inf.el" t t)
  require(finder-inf nil t)
  list-packages()
  eval((list-packages) nil)
  elisp--eval-last-sexp(t)
  eval-last-sexp(t)
  eval-print-last-sexp(nil)
  funcall-interactively(eval-print-last-sexp nil)
  call-interactively(eval-print-last-sexp nil nil)
  command-execute(eval-print-last-sexp)

Message #26 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: 30788 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Mats Lidell <mats.lidell <at> cag.se>
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Tue, 13 Mar 2018 20:07:20 +0100

> Note that the error occurs with LC_ALL=de_DE.UTF-8, whereas with
> LC_ALL=C or even LC_ALL=en_US.UTF-8 all seems to be fine.

More specifically, the problem seems to be triggered by the LC_NUMERIC
setting.

Message #29 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Tue, 13 Mar 2018 21:32:08 +0200

> Date: Tue, 13 Mar 2018 20:07:20 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>     Mats Lidell <mats.lidell <at> cag.se>
> From: Ulrich Mueller <ulm <at> gentoo.org>
> 
> > Note that the error occurs with LC_ALL=de_DE.UTF-8, whereas with
> > LC_ALL=C or even LC_ALL=en_US.UTF-8 all seems to be fine.
> 
> More specifically, the problem seems to be triggered by the LC_NUMERIC
> setting.

So you are saying that the problems happen when LC_NUMERIC sets a
locale whose decimal dot is not a period?  Is this relevant to 25.3 or
27 (or both)?

Anyway, what does that have to do with fontconfig?  Emacs arranges for
LC_NUMERIC to be "C" at startup (see fixup_locale); does this new
versio0n of fontconfig somehow countermands that?

Message #32 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Tue, 13 Mar 2018 21:06:40 +0100

>>>>> On Tue, 13 Mar 2018, Eli Zaretskii wrote:

> So you are saying that the problems happen when LC_NUMERIC sets a
> locale whose decimal dot is not a period?

I cannot say that this is the reason, only that the problem occurs
with de_DE.UTF-8 (and fr_FR.UTF-8 too) but not with en_US.UTF-8.

> Is this relevant to 25.3 or 27 (or both)?

Both.

> Anyway, what does that have to do with fontconfig?  Emacs arranges
> for LC_NUMERIC to be "C" at startup (see fixup_locale); does this
> new versio0n of fontconfig somehow countermands that?

I believe that this line in function FcConfigEnsure is the culprit
(present in 2.13.0 but not in 2.12.6):
https://cgit.freedesktop.org/fontconfig/tree/src/fccfg.c?h=2.13.0#n52

        setlocale (LC_ALL, "");

Patching that code out fixes the problem here.

Message #35 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Tue, 13 Mar 2018 22:26:11 +0100

Reported to fontconfig upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=105492

Message #40 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Wed, 14 Mar 2018 05:32:28 +0200

> Date: Tue, 13 Mar 2018 21:06:40 +0100
> Cc: 30788 <at> debbugs.gnu.org,
>     mats.lidell <at> cag.se
> From: Ulrich Mueller <ulm <at> gentoo.org>
> 
> > Anyway, what does that have to do with fontconfig?  Emacs arranges
> > for LC_NUMERIC to be "C" at startup (see fixup_locale); does this
> > new versio0n of fontconfig somehow countermands that?
> 
> I believe that this line in function FcConfigEnsure is the culprit
> (present in 2.13.0 but not in 2.12.6):
> https://cgit.freedesktop.org/fontconfig/tree/src/fccfg.c?h=2.13.0#n52
> 
>         setlocale (LC_ALL, "");
> 
> Patching that code out fixes the problem here.

OK, thanks.  Can you tell when this code is called from Emacs?  I
don't see any direct calls to FcConfigEnsure in the sources.

Message #43 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Wed, 14 Mar 2018 07:48:51 +0100

>>>>> On Wed, 14 Mar 2018, Eli Zaretskii wrote:

> OK, thanks.  Can you tell when this code is called from Emacs?
> I don't see any direct calls to FcConfigEnsure in the sources.

(gdb) bt
#0  FcConfigEnsure ()
    at /var/tmp/portage/media-libs/fontconfig-2.13.0/work/fontconfig-2.13.0/src/fccfg.c:40
#1  0x00007fffeeb2a849 in FcConfigInit ()
    at /var/tmp/portage/media-libs/fontconfig-2.13.0/work/fontconfig-2.13.0/src/fccfg.c:71
#2  0x00007fffeeb37c95 in IA__FcInit ()
    at /var/tmp/portage/media-libs/fontconfig-2.13.0/work/fontconfig-2.13.0/src/fcinit.c:192
#3  0x00007ffff44854b3 in XftInit (config=config <at> entry=0x0)
    at /var/tmp/portage/x11-libs/libXft-2.3.2/work/libXft-2.3.2/src/xftinit.c:33
#4  0x00000000004ea92b in xg_initialize () at gtkutil.c:5272
#5  0x00000000004d0a13 in x_term_init (
    display_name=display_name <at> entry=0x2c61b24, 
    xrm_option=xrm_option <at> entry=0x0, resource_name=0x2c676a8 "emacs-27-vcs")
    at xterm.c:12429
#6  0x00000000004d3797 in Fx_open_connection (display=0x2c61b24, 
    xrm_string=<optimized out>, must_succeed=0xc180) at xfns.c:5654
[...]

Message #46 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Wed, 14 Mar 2018 18:15:20 +0200

> Date: Wed, 14 Mar 2018 07:48:51 +0100
> Cc: 30788 <at> debbugs.gnu.org,
>     mats.lidell <at> cag.se
> From: Ulrich Mueller <ulm <at> gentoo.org>
> 
> >>>>> On Wed, 14 Mar 2018, Eli Zaretskii wrote:
> 
> > OK, thanks.  Can you tell when this code is called from Emacs?
> > I don't see any direct calls to FcConfigEnsure in the sources.
> 
> (gdb) bt
> #0  FcConfigEnsure ()
>     at /var/tmp/portage/media-libs/fontconfig-2.13.0/work/fontconfig-2.13.0/src/fccfg.c:40
> #1  0x00007fffeeb2a849 in FcConfigInit ()
>     at /var/tmp/portage/media-libs/fontconfig-2.13.0/work/fontconfig-2.13.0/src/fccfg.c:71
> #2  0x00007fffeeb37c95 in IA__FcInit ()
>     at /var/tmp/portage/media-libs/fontconfig-2.13.0/work/fontconfig-2.13.0/src/fcinit.c:192
> #3  0x00007ffff44854b3 in XftInit (config=config <at> entry=0x0)
>     at /var/tmp/portage/x11-libs/libXft-2.3.2/work/libXft-2.3.2/src/xftinit.c:33
> #4  0x00000000004ea92b in xg_initialize () at gtkutil.c:5272
> #5  0x00000000004d0a13 in x_term_init (
>     display_name=display_name <at> entry=0x2c61b24, 
>     xrm_option=xrm_option <at> entry=0x0, resource_name=0x2c676a8 "emacs-27-vcs")
>     at xterm.c:12429

Thanks.  So the patch below should fix the problem, I think.  Can you
test it?

diff --git a/src/xterm.c b/src/xterm.c
index c5163aa..7b445e5 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -12411,12 +12411,16 @@ x_term_init (Lisp_Object display_name, char *xrm_option, char *resource_name)
         unrequest_sigio (); /* See comment in x_display_ok.  */
         gtk_init (&argc, &argv2);
         request_sigio ();
-        fixup_locale ();
 
         g_log_remove_handler ("GLib", id);
 
         xg_initialize ();
 
+	/* Do this after the call to xg_initialize, because when
+	   Fontconfig is used, xg_initialize calls its initialization
+	   function which in some versions of Fontconfig calls setlocale.  */
+	fixup_locale ();
+
         dpy = DEFAULT_GDK_DISPLAY ();
 
 #if ! GTK_CHECK_VERSION (2, 90, 0)

Message #49 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Wed, 14 Mar 2018 18:57:28 +0100

>>>>> On Wed, 14 Mar 2018, Eli Zaretskii wrote:

> Thanks.  So the patch below should fix the problem, I think.  Can you
> test it?

> diff --git a/src/xterm.c b/src/xterm.c
> index c5163aa..7b445e5 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -12411,12 +12411,16 @@ x_term_init (Lisp_Object display_name, char *xrm_option, char *resource_name)
>          unrequest_sigio (); /* See comment in x_display_ok.  */
>          gtk_init (&argc, &argv2);
>          request_sigio ();
> -        fixup_locale ();
> 
>          g_log_remove_handler ("GLib", id);
> 
>          xg_initialize ();
> 
> +	/* Do this after the call to xg_initialize, because when
> +	   Fontconfig is used, xg_initialize calls its initialization
> +	   function which in some versions of Fontconfig calls setlocale.  */
> +	fixup_locale ();
> +
>          dpy = DEFAULT_GDK_DISPLAY ();
> 
>  #if ! GTK_CHECK_VERSION (2, 90, 0)

This fixes the problem (tested with fontconfig-2.13.0).

Note that it has also been fixed in the fontconfig git repository:
https://cgit.freedesktop.org/fontconfig/commit/?id=923b5be626a6e03fbaeee0b5cd6d0246c2f8f36f

Message #52 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Wed, 14 Mar 2018 20:15:43 +0200

> Date: Wed, 14 Mar 2018 18:57:28 +0100
> Cc: 30788 <at> debbugs.gnu.org,
>     mats.lidell <at> cag.se
> From: Ulrich Mueller <ulm <at> gentoo.org>
> 
> > +	/* Do this after the call to xg_initialize, because when
> > +	   Fontconfig is used, xg_initialize calls its initialization
> > +	   function which in some versions of Fontconfig calls setlocale.  */
> > +	fixup_locale ();
> > +
> >          dpy = DEFAULT_GDK_DISPLAY ();
> > 
> >  #if ! GTK_CHECK_VERSION (2, 90, 0)
> 
> This fixes the problem (tested with fontconfig-2.13.0).

Thanks, pushed to the release branch.

> Note that it has also been fixed in the fontconfig git repository:
> https://cgit.freedesktop.org/fontconfig/commit/?id=923b5be626a6e03fbaeee0b5cd6d0246c2f8f36f

I've seen that.  Does it really fix the problem?  What happens if you
run Emacs like so:

  $ LC_ALL=C emacs -Q

(If this works with the fixed version of fontconfig, then I guess I
completely misunderstand the issue.)

In any case, I think it's good for Emacs to be immune to buggy
versions of fontconfig, especially since we already needed to clean up
after similar problems in gtk_init.

Thanks.

Message #55 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Wed, 14 Mar 2018 22:19:45 +0100

>>>>> On Wed, 14 Mar 2018, Eli Zaretskii wrote:

>> Note that it has also been fixed in the fontconfig git repository:
>> https://cgit.freedesktop.org/fontconfig/commit/?id=923b5be626a6e03fbaeee0b5cd6d0246c2f8f36f

> I've seen that.  Does it really fix the problem?  What happens if you
> run Emacs like so:

>   $ LC_ALL=C emacs -Q

> (If this works with the fixed version of fontconfig, then I guess I
> completely misunderstand the issue.)

Indeed, the commit in fontconfig doesn't entirely fix it. While the
above command works (regardless of any other LANG and LC_* settings),
the following combination still fails: 

   $ unset LANG LC_ALL
   $ LC_NUMERIC=de_DE.UTF-8 emacs -Q

> In any case, I think it's good for Emacs to be immune to buggy
> versions of fontconfig, especially since we already needed to clean up
> after similar problems in gtk_init.

I agree, especially when the fix comes at no cost.

Message #58 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ulrich Mueller <ulm <at> gentoo.org>, 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Thu, 15 Mar 2018 22:45:09 -0400

tags 30788 fixed
close 30788 26.1
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Wed, 14 Mar 2018 18:57:28 +0100
>> Cc: 30788 <at> debbugs.gnu.org,
>>     mats.lidell <at> cag.se
>> From: Ulrich Mueller <ulm <at> gentoo.org>
>> 
>> > +	/* Do this after the call to xg_initialize, because when
>> > +	   Fontconfig is used, xg_initialize calls its initialization
>> > +	   function which in some versions of Fontconfig calls setlocale.  */
>> > +	fixup_locale ();
>> > +
>> >          dpy = DEFAULT_GDK_DISPLAY ();
>> > 
>> >  #if ! GTK_CHECK_VERSION (2, 90, 0)
>> 
>> This fixes the problem (tested with fontconfig-2.13.0).
>
> Thanks, pushed to the release branch.
>
>> Note that it has also been fixed in the fontconfig git repository:
>> https://cgit.freedesktop.org/fontconfig/commit/?id=923b5be626a6e03fbaeee0b5cd6d0246c2f8f36f

Now the setlocale has been removed from the library completely:

https://cgit.freedesktop.org/fontconfig/commit/?id=98eaef69af1350e459bf9c175476d3b772968874

Message #65 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: ulm <at> gentoo.org, 30788 <at> debbugs.gnu.org, mats.lidell <at> cag.se
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size: 1.0'
 when starting emacs -Q
Date: Fri, 16 Mar 2018 05:38:46 +0200

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Ulrich Mueller <ulm <at> gentoo.org>,  30788 <at> debbugs.gnu.org,  mats.lidell <at> cag.se
> Date: Thu, 15 Mar 2018 22:45:09 -0400
> 
> > Thanks, pushed to the release branch.
> >
> >> Note that it has also been fixed in the fontconfig git repository:
> >> https://cgit.freedesktop.org/fontconfig/commit/?id=923b5be626a6e03fbaeee0b5cd6d0246c2f8f36f
> 
> Now the setlocale has been removed from the library completely:
> 
> https://cgit.freedesktop.org/fontconfig/commit/?id=98eaef69af1350e459bf9c175476d3b772968874

As it should have been in the first place.

But we need that call to fixup_locale anyway, the change just moved it
to after xg_initialize.

Message #74 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: bug-gnu-emacs <at> gnu.org
Subject: bug#30788: 27.0.50;	Getting 'char-displayable-p: Invalid hash table
 rehash size: 1.0'	when starting emacs -Q
Date: Fri, 4 May 2018 23:58:17 +0200

Hello!

I am getting the same error after restarting my Mac. Reason was a set of updates for macOS High Sierra, Version 10.13.4. Only the X variant is hit, the NS variant has no problems at all.

Another change that happened recently is an upgrade of fontconfig to version 2.13.0.

The GNU Emacs 27.0.50 source is fetched with command "/usr/bin/git checkout -q 0bddbbc5aae621d5875880ac3e63f68d481df7c3" (whatever this means, the MacPorts package manager associates it with 20170918). The error remains even when re-compiling under the recent situation.

The GNU Emacs 27.0.50 launched weeks before the two updates worked OK with LANG=de_DE.UTF-8 LC_CTYPE=de_DE.UTF-8.


Configured using:
'configure --prefix=/opt/local --without-ns --without-dbus
--without-gconf --without-libotf --without-m17n-flt --without-gpm
--without-gnutls --with-xml2 --with-modules
'--enable-locallisppath=/Library/Application
Support/Emacs/calendar27:/Library/Application Support/Emacs' --infodir
/opt/local/share/info/emacs --with-ns CC=/usr/bin/clang 'CFLAGS=-pipe
-Os -arch x86_64' 'LDFLAGS=-L/opt/local/lib
-Wl,-headerpad_max_install_names -Wl,-no_pie -arch x86_64'
CPPFLAGS=-I/opt/local/include OBJC=/usr/bin/clang 'OBJCFLAGS=-pipe -Os
-arch x86_64''

Configured features:
JPEG RSVG IMAGEMAGICK NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS
MODULES LCMS2

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


--
Greetings

 Pete

"If I can't dance to it, it's not my revolution.“
				– A t-shirt designed by Jack Frager

Message #77 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Web.DE>
Cc: 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size:
 1.0'	when starting emacs -Q
Date: Fri, 04 May 2018 18:13:31 -0400

Peter Dyballa wrote:

> The GNU Emacs 27.0.50 source is fetched with command "/usr/bin/git
> checkout -q 0bddbbc5aae621d5875880ac3e63f68d481df7c3" (whatever this
> means, the MacPorts package manager associates it with 20170918).

It means you are building an 8-month old development version that
contains many bugs that have since been fixed, like this one.

Message #80 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50;	Getting 'char-displayable-p: Invalid hash
 table rehash size: 1.0'	when starting emacs -Q
Date: Sat, 5 May 2018 10:06:44 +0200

> Am 5.5.2018 um 00:13 schrieb Glenn Morris <rgm <at> gnu.org>:
> 
> Peter Dyballa wrote:
> 
>> The GNU Emacs 27.0.50 source is fetched with command "/usr/bin/git
>> checkout -q 0bddbbc5aae621d5875880ac3e63f68d481df7c3" (whatever this
>> means, the MacPorts package manager associates it with 20170918).
> 
> It means you are building an 8-month old development version that
> contains many bugs that have since been fixed, like this one.
> 
Thank you! I imagined that but was not so sure about it. Since the port is named "emacs-devel" it could have been something more recent …

Anyway, I reported the appearance of the bug to the port's maintainer.

--
Greetings

  Pete

A morning without coffee is like something without something else.

Message #83 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50;	Getting 'char-displayable-p: Invalid hash
 table rehash size: 1.0'	when starting emacs -Q
Date: Tue, 15 May 2018 16:02:28 +0200

> Am 5.5.2018 um 00:13 schrieb Glenn Morris <rgm <at> gnu.org>:
> 
> Peter Dyballa wrote:
> 
>> The GNU Emacs 27.0.50 source is fetched with command "/usr/bin/git
>> checkout -q 0bddbbc5aae621d5875880ac3e63f68d481df7c3" (whatever this
>> means, the MacPorts package manager associates it with 20170918).
> 
> It means you are building an 8-month old development version that
> contains many bugs that have since been fixed, like this one.
> 

I started a new attempt. On http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=15fa8de1ae3228413fde95e583008d9b9f19e7c7 I found this number. I patched a MacPorts control file and so port used the command '/usr/bin/git checkout -q 15fa8de1ae3228413fde95e583008d9b9f19e7c7' to fetch the sources. GNU Emacs 27.0.50 could be build, and it shows here on my Mac still the same error with the "Invalid hash table rehash size."

I also have two X servers installed (actually three). The one is XQuartz 2.7.11, which comes inside an Apple installer package, the other is X11, built from source by port from the sources of the packages xorg-server 1.18.4 or xorg-server-devel 1.19.99.1. What I can observe is that GNU Emacsen 26.x or 27.0.50 built in one X server do *not* run in that X server ("Invalid hash table rehash size"), but they *do* in the other.

--
Greetings

  Pete

You can learn many things from children.  How much patience you have, for instance.
				– Franklin P. Jones

Message #86 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Web.DE>
Cc: rgm <at> gnu.org, 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50;
 Getting 'char-displayable-p: Invalid hash table rehash size:
 1.0'	when starting emacs -Q
Date: Tue, 15 May 2018 20:06:37 +0300

> From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
> Date: Tue, 15 May 2018 16:02:28 +0200
> Cc: 30788 <at> debbugs.gnu.org
> 
> I started a new attempt. On http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=15fa8de1ae3228413fde95e583008d9b9f19e7c7 I found this number. I patched a MacPorts control file and so port used the command '/usr/bin/git checkout -q 15fa8de1ae3228413fde95e583008d9b9f19e7c7' to fetch the sources. GNU Emacs 27.0.50 could be build, and it shows here on my Mac still the same error with the "Invalid hash table rehash size."
> 
> I also have two X servers installed (actually three). The one is XQuartz 2.7.11, which comes inside an Apple installer package, the other is X11, built from source by port from the sources of the packages xorg-server 1.18.4 or xorg-server-devel 1.19.99.1. What I can observe is that GNU Emacsen 26.x or 27.0.50 built in one X server do *not* run in that X server ("Invalid hash table rehash size"), but they *do* in the other.

Based on previous similar problems, it's some snafu with locale
definitions and some software on your system that resets the locale's
LC_NUMERIC setting, which disrupts the Lisp reader's reading of X.Y
float values.  Does the workaround in

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30788#26

succeed to solve the problem in your case?

Message #89 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50; Getting 'char-displayable-p: Invalid hash
 table rehash size: 1.0'	when starting emacs -Q
Date: Tue, 15 May 2018 23:38:06 +0200

> Am 15.5.2018 um 19:06 schrieb Eli Zaretskii <eliz <at> gnu.org>:
> 
> Based on previous similar problems, it's some snafu with locale
> definitions and some software on your system that resets the locale's
> LC_NUMERIC setting, which disrupts the Lisp reader's reading of X.Y
> float values.  Does the workaround in
> 
>  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30788#26
> 
> succeed to solve the problem in your case?

Yes, this works. All other locales can be different. This works with GNU Emacs 26.x and 27.0.50.

In one desktop file I have "(normal-height . 0,5) (normal-width . 1.0)" (Emacs version 25.3.1)…

--
Greetings

  Pete

     _o    o         o   o
   _<<     \\_/\_,   \\_ \\_/\_,
  (*)/(*) (*)   (*) (*) `-    (*)

Message #92 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Web.DE>
Cc: rgm <at> gnu.org, 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50; Getting 'char-displayable-p: Invalid hash
 table rehash size: 1.0'	when starting emacs -Q
Date: Wed, 16 May 2018 05:30:24 +0300

> From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
> Date: Tue, 15 May 2018 23:38:06 +0200
> Cc: rgm <at> gnu.org,
>  30788 <at> debbugs.gnu.org
> 
> > Does the workaround in
> > 
> >  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30788#26
> > 
> > succeed to solve the problem in your case?
> 
> Yes, this works. All other locales can be different. This works with GNU Emacs 26.x and 27.0.50.
> 
> In one desktop file I have "(normal-height . 0,5) (normal-width . 1.0)" (Emacs version 25.3.1)…

So the next question is: which software resets the LC_NUMERIC setting?
Perhaps by running Emacs under a debugger with a breakpoint on
set_locale could answer that question.

Message #95 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50; Getting 'char-displayable-p: Invalid hash
 table rehash size: 1.0'	when starting emacs -Q
Date: Thu, 17 May 2018 01:22:15 +0200

> Am 16.5.2018 um 04:30 schrieb Eli Zaretskii <eliz <at> gnu.org>:
> 
> So the next question is: which software resets the LC_NUMERIC setting?
> Perhaps by running Emacs under a debugger with a breakpoint on
> set_locale could answer that question.

A few problems here… The newly built debugger (macOS High Sierra, version 10.13, obviously comes without one) needs to be "codesigned". This does not work here as in theory, practically. Maybe I need to reboot, disable that "gatekeeper" completely, or whatever. Is maybe root allowed to use GDB instantly?

The easiest step was to build two Emacsen with different levels of debug information.

BTW, GDB and I cannot find the text set_locale, except here:

../src/xterm.c:        /* gtk_init does set_locale.  Fix locale before and after.  */

I am using the athena variant with Xaw3d.

--
Greetings

  Pete      <\
             _\     O  _
            |o \  _\\_/-\='
_____________(_)|-(_)  (_)___________________________________

Message #98 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Web.DE>
Cc: rgm <at> gnu.org, 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50; Getting 'char-displayable-p: Invalid hash
 table rehash size: 1.0'	when starting emacs -Q
Date: Thu, 17 May 2018 17:56:55 +0300

> From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
> Date: Thu, 17 May 2018 01:22:15 +0200
> Cc: rgm <at> gnu.org,
>  30788 <at> debbugs.gnu.org
> 
> BTW, GDB and I cannot find the text set_locale, except here:

Sorry, it was my typo: I meant setlocale.

Message #101 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50; Getting 'char-displayable-p: Invalid hash
 table rehash size: 1.0'	when starting emacs -Q
Date: Sat, 19 May 2018 13:21:54 +0200

Could be Clang is *not* the proper compiler…

Of course code signing does not work after a reboot (bug report with Apple opened), so I used the root account for debugging. I started GDB 8.0.1 (installed as '-rwxr-xr-x  1 root  admin  6248012 17 Nov  2017 /opt/local/bin/ggdb') à la


	env LC_NUMERIC=de_DE.UTF-8 ggdb -i=mi emacs-27.0.50.1

Communication with GDB is:

...
	SIGINT is used by the debugger.
	Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
	DISPLAY = :0
	TERM = dumb
	(gdb) set args -Q
	(gdb) break setlocale
	Function "setlocale" not defined.
	Breakpoint 3 (setlocale) pending.
	(gdb) run
	Starting program: /Users/pete/Quellen/Emacs_CVS/emacs-27.0.50/src/emacs-27.0.50.1 -Q 
	[New Thread 0xf03 of process 8062]
	warning: unhandled dyld version (15)
	[New Thread 0x1007 of process 8062]
	[New Thread 0xd0f of process 8062]
	[New Thread 0x1603 of process 8062]
	xpr
	  C-c C-c[Inferior 1 (process 6709) exited normally]
	(gdb) xpr
	The history is empty.

Launched Emacs displays the error, but gdb does show any prompt. In the window *breakpopints of ...* is shown:

	Num Type       Disp Enb Addr               Hits What
	1   breakpoint keep y   0x000000010024a360 0    <terminate_due_to_signal>
	2   breakpoint del  y   0x00000001002928e0 0    <init_sys_modes>
	3   breakpoint keep y   <PENDING>          0    setlocale

I'll try anew with GCC!

--
Greetings

  Pete

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
				– Albert Einstein

Message #104 received at 30788 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Peter Dyballa <Peter_Dyballa <at> web.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30788 <at> debbugs.gnu.org
Subject: Re: bug#30788: 27.0.50; Getting 'char-displayable-p: Invalid hash
 table rehash size: 1.0' when starting emacs -Q
Date: Sat, 19 May 2018 13:45:06 +0200

[Message part 1 (text/plain, inline)]

Peter Dyballa <Peter_Dyballa <at> web.de> schrieb am Do., 17. Mai 2018 um
01:23 Uhr:

>
>
> > Am 16.5.2018 um 04:30 schrieb Eli Zaretskii <eliz <at> gnu.org>:
> >
> > So the next question is: which software resets the LC_NUMERIC setting?
> > Perhaps by running Emacs under a debugger with a breakpoint on
> > set_locale could answer that question.
>
> A few problems here… The newly built debugger (macOS High Sierra, version
> 10.13, obviously comes without one) needs to be "codesigned". This does not
> work here as in theory, practically. Maybe I need to reboot, disable that
> "gatekeeper" completely, or whatever. Is maybe root allowed to use GDB
> instantly?
>
> The easiest step was to build two Emacsen with different levels of debug
> information.
>
> BTW, GDB and I cannot find the text set_locale, except here:
>
> ../src/xterm.c:        /* gtk_init does set_locale.  Fix locale before and
> after.  */
>
> I am using the athena variant with Xaw3d.
>

Try using LLDB instead of GDB, it works better on macOS and doesn't require
codesigning.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.