Re: [Bug-xorriso] xorriso : FAILURE : Image size 2244690s exceeds free space on media -2036700157s

[Thomas Schmitt]

Hi,

uploaded is
  http://www.gnu.org/software/xorriso/xorriso-1.1.5.tar.gz
  Version timestamp :  2011.08.19.110340
  MD5: d8d8378d382e3ddb27b0b6191d756c11

The remaining memory leak stems from Linux function getpwuid()
which is called by libacl.
According to its man page, the caller is not supposed to free the
data returned by this function. So it seems to be buffer memory,
which gets allocated once per process and is then re-used for
each getpwuid() call. I.e. Linux libacl is not to blame either.


---------------------------------------------------------------------

I further investigated why my tests on Solaris never ran into the fake
memory shortage. nl_langinfo(CODESET) returns "646", the Solaris name
of US-ASCII. (Probably stemming from ISO-646 aka ECMA-6.)
Solaris iconv_open(3) is not willing to convert from "646" to "ASCII"
although both names are known and actually aliases of each other:
  $ iconv -l | grep ASCII
    646 (ASCII, US-ASCII, US_ASCII, USASCII),
  $ echo hello | iconv -f 646 -t ASCII
  Not supported 646 to ASCII
  $ echo hello | iconv -f 646 -t UTF-8
  hello

So on my Solaris, not only the 2-step conversion "646"->"WCHAR_T"->"ASCII"
fails, but also "646"->"ASCII". This avoids the malloc() with the bad
if-condition. Finally the fallback mechanism kicks in and assumes an
ASCII-compatible 8-bit character set. It replaces characters < 32
or > 126 by underscores.
This hits the ECMA-119 names, which are normally the ones used by
boot loaders. But they are from a restricted, case insensitive 7-bit
character set anyway. So i assume that the fallback conversion is ok
here.


Have a nice day :)

Thomas