Subject: Re: Strange segmentation fault trying to run postgresql on
To: =?ISO-8859-1?Q?R=E9mi_Zara?= <remi.zara@free.fr>
From: Alex Pelts <alexp@broadcom.com>
List: port-cobalt
Date: 04/30/2007 11:04:30
Your conclusions are not exactly correct, at least from the assembly=20
code that you have posted on 2 previous occasions.

Exception happens between calls to
progname =3D get_progname(argv[0]);
and
startup_hacks(progname);
while trying to store result of get_progname function in to progname=20
variable.

Somehow the address of progname pointer comes out not to be word=20
aligned. I would imagine a problem with compiler or linker.

Regards,
Alex

R=E9mi Zara wrote:
>=20
> Le 30 avr. 07 =E0 05:54, Alex Pelts a =E9crit :
>=20
>> You can see that v0 is loaded from memory location pointed by gp. I=20
>> guess some sort of small data area optimization of some sort. The=20
>> offset is a bit large for the structure access. Unless it is array or=20
>> a large structure.
>>
>> You also need to post c source that generates this code.
>=20
> You can read the c source here:
>=20
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/main/main.=
c?rev=3D1.108;content-type=3Dtext%2Fx-cvsweb-markup=20
>=20
>=20
> The app crashes before the call to save_ps_display_args, but after the=20
> call to get_progname(argv[0]) which seems to be returning a correct val=
ue.
> startup_hacks(progname) gets optimized out (because it turns out empty)=
=20
> at -O2
>=20
>> I run in to similar problem when code would run on linux but would=20
>> produce exception on nucleus and vxworks. Turned out that linux=20
>> exception handler would recover from unaligned access by loading=20
>> register and continuing program. Maybe this is the case for this=20
>> application as well. No one checked this app on mips.
>>
>=20
> PostgreSQL builds and runs OK on debian 3.1 MIPS, but maybe it's due to=
=20
> the unaligned trap handler
>=20
> Regards,
>=20
> R=E9mi Zara