Обсуждение: Re: [GENERAL] OS X 10.11.3, psql, bus error 10, 9.5.1

Поиск
Список
Период
Сортировка

Re: [GENERAL] OS X 10.11.3, psql, bus error 10, 9.5.1

От
Tom Lane
Дата:
I wrote:
> That's confusing because it implies that -fno-common is the default,
> which it evidently is not.  But anyway, my diagnosis is that you're
> breaking something about the linker's behavior with that switch.

Oh!  Looking closer, the core dump happens here:

const printTextFormat pg_utf8format;
printTextFormat *popt = (printTextFormat *) &pg_utf8format;

-->    popt->name = "unicode";

So apparently, the relevant property of "-fno-common" is that it
causes "const" variables to actually get placed in read-only data.

I think this code is new in 9.5, which'd explain why you didn't see
the failure with older PG versions.  It's surely busted though.

I shall get rid of the const-ness, as well as the lame casting away
of it, and I think I will also go make buildfarm member longfin use
"-fno-common".  It is truly sad that we apparently have no test
machine that enforces that const means const ...
        regards, tom lane



Re: [GENERAL] OS X 10.11.3, psql, bus error 10, 9.5.1

От
Chris Ruprecht
Дата:
unfortunately, I have to admit to my disgrace, that I'm still no C programmer after all these decades of dabbling in
writingcode. I just used the flags because someone at some point told me that it was a good idea, turns out, it's not
[always].I shall rebuild 9.5.1 without the -fno-common flag and see if that fixes things. 

Thanks Tom for spending part of your weekend on this.

Chris.


> On Mar 12, 2016, at 17:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
>> That's confusing because it implies that -fno-common is the default,
>> which it evidently is not.  But anyway, my diagnosis is that you're
>> breaking something about the linker's behavior with that switch.
>
> Oh!  Looking closer, the core dump happens here:
>
> const printTextFormat pg_utf8format;
>
>     printTextFormat *popt = (printTextFormat *) &pg_utf8format;
>
> -->    popt->name = "unicode";
>
> So apparently, the relevant property of "-fno-common" is that it
> causes "const" variables to actually get placed in read-only data.
>
> I think this code is new in 9.5, which'd explain why you didn't see
> the failure with older PG versions.  It's surely busted though.
>
> I shall get rid of the const-ness, as well as the lame casting away
> of it, and I think I will also go make buildfarm member longfin use
> "-fno-common".  It is truly sad that we apparently have no test
> machine that enforces that const means const ...
>
>             regards, tom lane




Re: [GENERAL] OS X 10.11.3, psql, bus error 10, 9.5.1

От
Greg Stark
Дата:
<p dir="ltr"><br /> On 12 Mar 2016 10:58 pm, "Tom Lane" <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br /> ><br /> > I wrote:<br /> > > That's
confusingbecause it implies that -fno-common is the default,<br /> > > which it evidently is not.  But anyway, my
diagnosisis that you're<br /> > > breaking something about the linker's behavior with that switch.<p
dir="ltr">>I shall get rid of the const-ness, as well as the lame casting away<br /> > of it, and I think I will
alsogo make buildfarm member longfin use<br /> > "-fno-common".  It is truly sad that we apparently have no test<br
/>> machine that enforces that const means const ...<p dir="ltr">It looks like this would also be useful for
catchingany mistakes where we might have defined a variable in two different files or missed an "extern". Though I'm
notsure the failures will be very obvious. 

Re: [GENERAL] OS X 10.11.3, psql, bus error 10, 9.5.1

От
Tom Lane
Дата:
Greg Stark <stark@mit.edu> writes:
> On 12 Mar 2016 10:58 pm, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>> I shall get rid of the const-ness, as well as the lame casting away
>> of it, and I think I will also go make buildfarm member longfin use
>> "-fno-common".  It is truly sad that we apparently have no test
>> machine that enforces that const means const ...

> It looks like this would also be useful for catching any mistakes where we
> might have defined a variable in two different files or missed an "extern".
> Though I'm not sure the failures will be very obvious.

The answer is that a failure looks like this:

duplicate symbol _FeBeWaitSet in:   access/common/printtup.o   access/transam/parallel.o
duplicate symbol _FeBeWaitSet in:   access/common/printtup.o   commands/async.o
duplicate symbol _FeBeWaitSet in:   access/common/printtup.o   commands/copy.o
duplicate symbol _FeBeWaitSet in:   access/common/printtup.o   libpq/be-secure.o
duplicate symbol _FeBeWaitSet in:   access/common/printtup.o   libpq/auth.o
duplicate symbol _FeBeWaitSet in:   access/common/printtup.o   libpq/hba.o
duplicate symbol _FeBeWaitSet in:   access/common/printtup.o   libpq/pqcomm.o
... etc etc ...

See:

http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2016-03-21%2011%3A49%3A13

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7fa0064092e135415a558dc3c4d7393d14ab6d8e
        regards, tom lane