Re: Bus error in formatting.c NUM_numpart_to_char (9.4.12, 9.6.3, sparc)

From: "Tom Turelinckx" <tom(at)turelinckx(dot)be>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Bus error in formatting.c NUM_numpart_to_char (9.4.12, 9.6.3, sparc)
Date: 2017-06-27 13:22:10
Message-ID: 00ac01d2ef48$6288c520$279a4f60$@turelinckx.be
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Turelinckx wrote:

> Switching to gcc-4.7 does not solve the alignment issue in 9.4.7 (resolved in 9.4.8) discussed here:
>
> https://www.postgresql.org/message-id/20160413094117.GC21485@msg.credativ.de
>
> Tom Lane wrote:
>
> > We never did get a clear explanation of why that crashed on Sparc.

With gcc 4.7, against postgresql 9.4.7.

Clean 9.4.7 fails contrib/test-decoding:

LOG: server process (PID 18295) was terminated by signal 10: Bus error
DETAIL: Failed process was running: SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');

Reading symbols from /home/turelto/src/947/original/postgresql-9.4-9.4.7/build/src/backend/postgres...done.
[New LWP 18295]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: turelto regression [local] SELECT '.
Program terminated with signal 10, Bus error.
#0 ReorderBufferRestoreChange (data=0x5e1acf "", txn=0x6143a0, rb=0x614318)
at /home/turelto/src/947/original/postgresql-9.4-9.4.7/build/../src/backend/replication/logical/reorderbuffer.c:2327
2327 Size tuplelen = ((HeapTuple) data)->t_len;
(gdb) l
2322 data += tuplelen;
2323 }
2324
2325 if (change->data.tp.newtuple)
2326 {
2327 Size tuplelen = ((HeapTuple) data)->t_len;
2328
2329 change->data.tp.newtuple =
2330 ReorderBufferGetTupleBuf(rb, tuplelen - offsetof(HeapTupleHeaderData, t_bits));
2331

After applying this commit from 9.4.8 against 9.4.7, patched 9.4.7 passes all tests:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0045691

Assembly snippet around line 2327 before patching:

.LBB695:
.LBB694:
.loc 3 52 0
mov 20, %o2
add %o0, 4, %o0
.LVL301:
call memcpy, 0
add %l6, %l4, %l7
.LVL302:
.LBE694:
.LBE695:
.loc 1 2318 0
ld [%l5+28], %g2
.LBB696:
.LBB697:
.loc 3 52 0
mov %l6, %o1
mov %l4, %o2
.LBE697:
.LBE696:
.loc 1 2318 0
add %g2, 35, %g1
and %g1, -8, %g1
.loc 1 2317 0
st %g1, [%g2+20]
.LVL303:
.loc 1 2321 0
ld [%l5+28], %g1
.LBB699:
.LBB698:
.loc 3 52 0
call memcpy, 0
ld [%g1+20], %o0
.LVL304:
.LBE698:
.LBE699:
.LBE691:
.loc 1 2325 0
ld [%l5+32], %g1
.L355:
cmp %g1, 0
be,a,pn %icc, .L356
ld [%i1+84], %g2
.LBB700:
.loc 1 2327 0
ld [%l7], %l6
.LVL305:
.loc 1 2330 0
mov %i0, %o0
call ReorderBufferGetTupleBuf, 0
add %l6, -23, %o1
.LVL306:
.loc 1 2329 0
st %o0, [%l5+32]
.LVL307:
.LBB701:
.LBB702:
.loc 3 52 0
mov %l7, %o1
mov 20, %o2
.LVL308:
call memcpy, 0
add %o0, 4, %o0
.LVL309:
.LBE702:
.LBE701:
.loc 1 2339 0
ld [%l5+32], %g1
.LBB703:
.LBB704:
.loc 3 52 0
add %l7, 20, %o1
.LVL310:
mov %l6, %o2
.LBE704:
.LBE703:
.loc 1 2339 0
add %g1, 35, %g2
and %g2, -8, %g2
.loc 1 2338 0
st %g2, [%g1+20]
.LVL311:
.loc 1 2342 0
ld [%l5+32], %g1
.LBB706:
.LBB705:
.loc 3 52 0
call memcpy, 0
ld [%g1+20], %o0
.LVL312:
.LBE705:
.LBE706:
.LBE700:
.LBB707:
.LBB708:

Assembly snippet after patching:

.LBB699:
.LBB698:
.loc 3 52 0
mov 20, %o2
add %o0, 4, %o0
.LVL301:
call memcpy, 0
add %l6, %l4, %l7
.LVL302:
.LBE698:
.LBE699:
.loc 1 2322 0
ld [%l5+28], %g2
.LBB700:
.LBB701:
.loc 3 52 0
mov %l6, %o1
mov %l4, %o2
.LBE701:
.LBE700:
.loc 1 2322 0
add %g2, 35, %g1
and %g1, -8, %g1
.loc 1 2321 0
st %g1, [%g2+20]
.LVL303:
.loc 1 2325 0
ld [%l5+28], %g1
.LBB703:
.LBB702:
.loc 3 52 0
call memcpy, 0
ld [%g1+20], %o0
.LVL304:
.LBE702:
.LBE703:
.LBE695:
.loc 1 2329 0
ld [%l5+32], %g1
.L355:
cmp %g1, 0
be,a,pn %icc, .L356
ld [%i1+84], %g2
.LVL305:
.LBB704:
.LBB705:
.LBB706:
.loc 3 52 0
ldub [%l7], %g1
.LBE706:
.LBE705:
.loc 1 2338 0
mov %i0, %o0
.LBB708:
.LBB707:
.loc 3 52 0
stb %g1, [%fp-1036]
.LVL306:
ldub [%l7+1], %g1
stb %g1, [%fp-1035]
ldub [%l7+2], %g1
stb %g1, [%fp-1034]
ldub [%l7+3], %g1
stb %g1, [%fp-1033]
.LBE707:
.LBE708:
.loc 1 2338 0
ld [%fp-1036], %o1
call ReorderBufferGetTupleBuf, 0
add %o1, -23, %o1
.LVL307:
.loc 1 2337 0
st %o0, [%l5+32]
.LVL308:
.LBB709:
.LBB710:
.loc 3 52 0
mov %l7, %o1
mov 20, %o2
.LVL309:
call memcpy, 0
add %o0, 4, %o0
.LVL310:
.LBE710:
.LBE709:
.loc 1 2347 0
ld [%l5+32], %g1
.LBB711:
.LBB712:
.loc 3 52 0
add %l7, 20, %o1
.LVL311:
ld [%fp-1036], %o2
.LBE712:
.LBE711:
.loc 1 2347 0
add %g1, 35, %g2
and %g2, -8, %g2
.loc 1 2346 0
st %g2, [%g1+20]
.LVL312:
.loc 1 2350 0
ld [%l5+32], %g1
.LBB714:
.LBB713:
.loc 3 52 0
call memcpy, 0
ld [%g1+20], %o0
.LVL313:
.LBE713:
.LBE714:
.LBE704:
.LBB715:
.LBB716:

Best regards,
Tom Turelinckx

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2017-06-27 15:32:44 Re: BUG #14719: Logical replication unexpected behaviour when target table has missing columns
Previous Message devrim 2017-06-27 12:36:56 Re: libpq.so.5 dependancy error installing pgsql onto linux 6.