Date: Sat, 30 Dec 2006 23:23:13 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Alejandro Pulver <alepulver@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Program not being executed at all Message-ID: <20061230212313.GS21325@deviant.kiev.zoral.com.ua> In-Reply-To: <20061230181201.20ade388@phobos.mars.bsd> References: <20061230024718.22131bff@phobos.mars.bsd> <20061230122149.GM21325@deviant.kiev.zoral.com.ua> <20061230111559.760a497b@phobos.mars.bsd> <20061230143103.GP21325@deviant.kiev.zoral.com.ua> <20061230181201.20ade388@phobos.mars.bsd>
next in thread | previous in thread | raw e-mail | index | archive | help
--rVDsP1EMu6KJGDpG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Dec 30, 2006 at 06:12:01PM -0300, Alejandro Pulver wrote:
> On Sat, 30 Dec 2006 16:31:03 +0200
> Kostik Belousov <kostikbel@gmail.com> wrote:
>=20
> [...]
> > > > > Interestingly 'ldd' also crashes when examining it, outputting the
> > > > > following (however 'ktrace' has more information):
> > > > >=20
> > > > > /usr/local/bin/quake2max:
> > > > > /usr/local/bin/quake2max: signal 6
> > > > >=20
> [...]
> > > > Please, show the output of the commands
> > > > file /usr/local/bin/quake2max
> > > > readelf -ld /usr/local/bin/quake2max
> > > >=20
> [...]
> > Signal 6 is sent by elf image activator upon exec() when old address sp=
ace
> > is destroyed, but new image cannot be loaded. In your case, I guess that
> > extra large bss section size (where uninitialized global/static variabl=
es
> > are placed) causes loader to fail:
> >=20
> > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg A=
lign
> > > LOAD 0x073000 0x080bb000 0x080bb000 0x02cc4 0x28a20e34 RW=
0x1000
> >=20
> > Look at MemSiz column. VirtAddr + MemSiz >=3D 0x30000000, and elf inter=
preter
> > (/libexec/ld-elf.so.1) is usually mmapped at 0x28000000.
> >=20
> > Look at the source for huge global arrays/objects.
>=20
> Hello.
>=20
> Thank you very much for your help, I have found the array; see below.
>=20
> I searched the diff for increments in the macros (it has many global
> arrays of a size defined with '#define') and the only thing I could
> find is the following:
>=20
> -#define MAX_DECAL_FRAGMENTS 32
> +#define MAX_DECAL_FRAGMENTS 64
>=20
> But the problem is here:
>=20
> #define MAX_PARTICLES 4096
>=20
> typedef struct particle_s
> {
> /* skip */
> decalpolys_t decal[MAX_DECAL_FRAGMENTS];
> /* skip */
> } cparticle_t;
>=20
> cparticle_t particles[MAX_PARTICLES];
>=20
> The size of the cparticle_t type is 68 in my machine. So 68*32*4096 =3D
> 8912896, and in the new version it was doubled to 17825792.
In fact, it shall be bigger due to alignment.
>=20
> I have changed the definition back to 32, and now 'readelf' reports the
> size has been reduced considerably:
>=20
> LOAD 0x070000 0x080b8000 0x080b8000 0x03010 0x149a1954 RW 0x=
1000
>=20
> BTW this works in Linux (I haven't tried myself but someone else told
> me), so just for curiosity, does it allocate more memory for loading
> programs?
>=20
> Best Regards,
> Ale
This is not how much memory is allocated for loading, this is the address
map that determines max size of the data/bss section.
I don't remember the typical address where linux places mmaped regions
and elf interpreter, and do not have accessible machine to check. Most
likely, this address is higher for linux.
The array of such size (I think up to 1-1.5 Gb) could be easily allocated
dynamically by mmap(2).
--rVDsP1EMu6KJGDpG
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFFltjBC3+MBN1Mb4gRAjW/AKDxZ2anuAyYdj2oQGJ3fsvx8F2guQCgrAT+
b7v5/G6x0tpABI/3531qKwQ=
=hedP
-----END PGP SIGNATURE-----
--rVDsP1EMu6KJGDpG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061230212313.GS21325>