[From nobody Tue Jul 14 10:33:07 2026
Received: (at submit) by bugs.debian.org; 7 Mar 2018 00:33:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.1-bugs.debian.org_2005_01_02
 (2015-04-28) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-17.2 required=4.0 tests=BAYES_00,FROMDEVELOPER,
 HAS_PACKAGE,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H2,SPF_PASS,TXREP autolearn=ham autolearn_force=no
 version=3.4.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 32; hammy, 150; neutral, 93; spammy,
 0. spammytokens: hammytokens:0.000-+--littleendian, 0.000-+--little-endian,
 0.000-+--testsuite, 0.000-+--H*F:U*jrtc27,
 0.000-+--Hx-spam-relays-external:sk:jrtc27@
Return-path: <jrtc27@jrtc27.com>
Received: from mail-wr0-f180.google.com ([209.85.128.180])
 by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.89) (envelope-from <jrtc27@jrtc27.com>) id 1etN14-0002Qf-Vc
 for submit@bugs.debian.org; Wed, 07 Mar 2018 00:33:11 +0000
Received: by mail-wr0-f180.google.com with SMTP id n7so431835wrn.5
 for <submit@bugs.debian.org>; Tue, 06 Mar 2018 16:33:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:content-transfer-encoding:mime-version
 :subject:message-id:date:to;
 bh=VgEajsC4pSZrMpMPInEKycQ6NHjA+HyyFPZniDX7oXI=;
 b=e4EjdgE0IP5XKil4ejXXgdZGOK3QZDh6nnzpyHf3detoqXEdU/aSgC0THlxfCFuGRH
 ihj9jkCy2mllbK458qOEFL8OI9SBa5/pU/sCMTFqTfvKm+uOI5aQfpybUO+v++EwhjyF
 X++cZqPo1914AlhY4f/gz32jjYbwMgjWeukNLbrdDToDg4+uGTLRW5AS9WpoxnNuk+KW
 iO6iUxHhOQNoqeGl7/Rw07Jj3K/t+63t0MbGOMVH2m1MSYTLcPHslV4Yz5gr+hyQLfGl
 K0TnPpcMdgbODmo8OXrgPV7QVXIH4TANdzx11MD/DHfv//CuBFxs3WxhiFJWUtcSMfQ/
 4WMA==
X-Gm-Message-State: APf1xPDN7jtDiN7bOEpCPwYnXgIk/F+DGtXO/1KrRBJl1F1Yv50Q+nwG
 8kqElJpyKc7zLdeS4k/u7Jeku1WLA5I=
X-Google-Smtp-Source: AG47ELuRgSnHLgYhnLefg7CkeOVNgqUNE59VeM26m9d/g5cbUFzwwYL+5BxUr5kK8Pe23OrWY3nctw==
X-Received: by 10.223.190.134 with SMTP id i6mr17553152wrh.157.1520382787251; 
 Tue, 06 Mar 2018 16:33:07 -0800 (PST)
Received: from jrtc4a.trin.private.cam.ac.uk
 (global-184-8.nat-1.net.cam.ac.uk. [131.111.184.8])
 by smtp.gmail.com with ESMTPSA id k2sm9074532wmf.10.2018.03.06.16.33.06
 for <submit@bugs.debian.org>
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 06 Mar 2018 16:33:06 -0800 (PST)
From: James Clarke <jrtc27@debian.org>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: libsphinxbase3: Causes pocketsphinx to FTBFS on 64-bit big-endian
 architectures (fills testsuite logs on disk with errors)
Message-Id: <72A48F80-A464-4F1C-8EA5-88B1FC93C235@debian.org>
Date: Wed, 7 Mar 2018 00:33:05 +0000
To: Debian Bug Tracking System <submit@bugs.debian.org>
X-Mailer: Apple Mail (2.3445.5.20)
Delivered-To: submit@bugs.debian.org

Package: libsphinxbase3
Version: 0.8+5prealalpha+1-1
Severity: important
Tags: upstream
Control: affects -1 src:pocketsphinx

Hi,
The build for pocketsphinx fails on 64-bit big-endian architectures, =
failing
with "No space left on device", as the testsuite log files fill up with
hundreds of gigabytes of warnings. The first indication of the problem =
in the
log files is:

> Sorry, this does not support more than 33554432 n-grams of a =
particular order.  Edit util/bit_packing.hh and fix the bit packing =
functions

where 33554432 is 0x2000000, i.e. 32 byte-swapped. This error isn't =
fatal
though, and libsphinxbase3 continues to try to build the trie, with tons =
of
duplicate word warnings, as it's reading all kinds of garbage. The =
issues stem
from a widespread use of using fread to read multi-byte values with no =
regard
for their endianness, with the first error, the wrong number of n-grams, =
coming
from reading into the "counts" array in ngram_model_trie_read_bin. The =
library
has functions like bio_fread which can do the byte-swapping for the =
caller, so
presumably these should be used instead, though for this file format =
there does
not seem to be an easy way to determine the endianness of the file based =
on
some header magic like for some of the others (but maybe it's intended =
to
always be little-endian).

32-bit big-endian architectures have the same underlying bugs, but it =
seems
they die a lot earlier, failing to calloc huge sizes (presumably these =
same
calls are made on 64-bit architectures but can be satisfied thanks to
overcommitting) and thus don't actually try to build the trie and spew =
all the
warnings.

There are "only" 62 calls to fread in sphinxbase (and a further 45 in
pocketsphinx) so it shouldn't be too hard for someone with knowledge of =
the
codebase to audit their uses, especially since my guess is that most of =
them
can be turned into something like `bio_fread(..., IS_BIG_ENDIAN)`. =
Similarly,
the corresponding fwrite calls should be audited too.

Regards,
James
]