patgen SIGSEGV on aarch64-linux

Johannes Hielscher jhielscher at
Tue Jul 16 02:24:49 CEST 2019

> Alternatively, does increasing swap on your machine solve it?
Good hint! More swap ⇒ higher limits until patgen segfaults (run time).
Even the lame zram trick helps in lifting the limits.

Hence, given that the trie{,c}_size sum essentially conducts a test of
accessible memory at run time, this
  * explains the inconsistent results and the odd numbers which Keno
    and me found out the hard way,
  * means RAM limitations for running and compiling patgen (running
  * enables power users with memory-laden machines to modify
    for virtually infinite dictionary sizes.

There are no “right” numbers for trie{,c}_size in an absolute sense (We
can't know the machines a user will run patgen on), and it's just luck
that nobody on x86_64-linux (or another “large” platform) had such
little RAM in their box to find that issue there.

Which values should be shipped with the TL sources? With plenty of zram,
both my boxes would even be happy with Keno's original

A notice like
> If patgen is segfaulting on runtime, reduce the trie{,c}_size values,
> or (better) increase RAM or swap size of your machine.
could be added to the comments in, so that future
builders/users don't have to go through all this again.


More information about the tex-live mailing list