Date: Sat, 30 Dec 2006 18:12:01 -0300 From: Alejandro Pulver <alepulver@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Program not being executed at all Message-ID: <20061230181201.20ade388@phobos.mars.bsd> In-Reply-To: <20061230143103.GP21325@deviant.kiev.zoral.com.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_UDXHvbju6jV=7sbfOgZrm_Y
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Sat, 30 Dec 2006 16:31:03 +0200
Kostik Belousov <kostikbel@gmail.com> wrote:
[...]
> > > > 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 space
> is destroyed, but new image cannot be loaded. In your case, I guess that
> extra large bss section size (where uninitialized global/static variables
> are placed) causes loader to fail:
>=20
> > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Ali=
gn
> > LOAD 0x073000 0x080bb000 0x080bb000 0x02cc4 0x28a20e34 RW =
0x1000
>=20
> Look at MemSiz column. VirtAddr + MemSiz >=3D 0x30000000, and elf interpr=
eter
> (/libexec/ld-elf.so.1) is usually mmapped at 0x28000000.
>=20
> Look at the source for huge global arrays/objects.
Hello.
Thank you very much for your help, I have found the array; see below.
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:
-#define MAX_DECAL_FRAGMENTS 32
+#define MAX_DECAL_FRAGMENTS 64
But the problem is here:
#define MAX_PARTICLES 4096
typedef struct particle_s
{
/* skip */
decalpolys_t decal[MAX_DECAL_FRAGMENTS];
/* skip */
} cparticle_t;
cparticle_t particles[MAX_PARTICLES];
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.
I have changed the definition back to 32, and now 'readelf' reports the
size has been reduced considerably:
LOAD 0x070000 0x080b8000 0x080b8000 0x03010 0x149a1954 RW 0x10=
00
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?
Best Regards,
Ale
--Sig_UDXHvbju6jV=7sbfOgZrm_Y
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFFltY0iV05EpRcP2ERAqTQAKCa69gkcO2u2suMLvoiC0vTSvDK9QCeOe51
bZ2dB/osuCGrRWE7Mg2mgac=
=lAZ9
-----END PGP SIGNATURE-----
--Sig_UDXHvbju6jV=7sbfOgZrm_Y--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061230181201.20ade388>