Bug 1202696 - ppc64: slaptest segfault in openldap-2.4.40 [NEEDINFO]
Summary: ppc64: slaptest segfault in openldap-2.4.40
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap
Version: 6.7
Hardware: ppc64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Synacek
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-17 08:53 UTC by Patrik Kis
Modified: 2015-07-22 06:18 UTC (History)
8 users (show)

Fixed In Version: openldap-2.4.40-3.el6
Doc Type: Bug Fix
Doc Text:
* A segmentation fault could cause the server to terminate unexpectedly on IBM Power Systems. A code optimization that caused this problem has been removed, preventing the segmentation fault from occurring. As a result, the server no longer crashes in this situation. (BZ#1202696)
Clone Of:
Environment:
Last Closed: 2015-07-22 06:18:52 UTC
jsynacek: needinfo? (jakub)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1292 normal SHIPPED_LIVE openldap bug fix and enhancement update 2015-07-20 17:48:41 UTC
OpenLDAP ITS 8084 None None None Never

Comment 6 Marek Polacek 2015-03-18 11:08:45 UTC
I think it's premature to throw this at gcc right away.  Can you try building slapd with -O2 -fwrapv -fno-strict-aliasing?  If that helps, then it's likely a bug in the slapd code.  If that doesn't help, try -O0.  If -O0 helps, we'll need to bisect between -O2 and -O0 compiled objects the problematic one.

Comment 7 Jan Synacek 2015-03-18 14:22:46 UTC
Adding " -O0 -fwrapv -fno-strict-aliasing" to CFLAGS still segfaults, only the backtrace is slightly different. Changing -O0 to -O2 doesn't seem to make any difference.

(gdb) bt
#0  0x0000000052e6a624 in 0000088e.plt_call.mmap@@GLIBC_2.3+0 ()
#1  0x0000000052e6aed4 in mdb_env_create (env=0xfffb6f50010) at ../../../../libraries/liblmdb/mdb.c:3662
#2  0x0000000052d4b5ac in mdb_db_open (be=0x5304fae0, cr=0xfffffffe9a4) at ../../../../servers/slapd/back-mdb/init.c:115
#3  0x0000000052c3f1e4 in backend_startup_one (be=0x5304fae0, cr=0xfffffffe9a4) at ../../../servers/slapd/backend.c:224
#4  0x0000000052c3f9d0 in backend_startup (be=0x5304fae0) at ../../../servers/slapd/backend.c:325
#5  0x0000000052c7dfa4 in slap_startup (be=0x0) at ../../../servers/slapd/init.c:219
#6  0x0000000052bf0d80 in main (argc=6, argv=0xffffffff128) at ../../../servers/slapd/main.c:991

Notice that the first frame is now mmap instead of calloc, but frame 1 is still the same line as before:

(gdb) f 1
#1  0x0000000052e6aed4 in mdb_env_create (env=0xfffb6f50010) at ../../../../libraries/liblmdb/mdb.c:3662
3662		e = calloc(1, sizeof(MDB_env));

(gdb) f 0
#0  0x0000000052e6a624 in 0000088e.plt_call.mmap@@GLIBC_2.3+0 ()
(gdb) dissasemble
Undefined command: "dissasemble".  Try "help".
(gdb) disassemble 
Dump of assembler code for function 0000088e.plt_call.mmap@@GLIBC_2.3+0:
   0x0000000052e6a620 <+0>:	std     r2,40(r1)
=> 0x0000000052e6a624 <+4>:	ld      r11,-27024(r2)
   0x0000000052e6a628 <+8>:	mtctr   r11
   0x0000000052e6a62c <+12>:	ld      r2,-27016(r2)
   0x0000000052e6a630 <+16>:	cmpldi  r2,0
   0x0000000052e6a634 <+20>:	bnectr+ 
   0x0000000052e6a638 <+24>:	.long 0x47fff490

(gdb) f 1
#1  0x0000000052e6aed4 in mdb_env_create (env=0xfffb6f50010) at ../../../../libraries/liblmdb/mdb.c:3662
3662		e = calloc(1, sizeof(MDB_env));
(gdb) disassemble 
Dump of assembler code for function mdb_env_create:
   0x0000000052e6aeb0 <+0>:	mflr    r0
   0x0000000052e6aeb4 <+4>:	std     r0,16(r1)
   0x0000000052e6aeb8 <+8>:	std     r31,-8(r1)
   0x0000000052e6aebc <+12>:	stdu    r1,-144(r1)
   0x0000000052e6aec0 <+16>:	mr      r31,r1
   0x0000000052e6aec4 <+20>:	std     r3,192(r31)
   0x0000000052e6aec8 <+24>:	li      r3,1
   0x0000000052e6aecc <+28>:	li      r4,248
   0x0000000052e6aed0 <+32>:	bl      0x52e6a604 <0000088e.plt_call.calloc@@GLIBC_2.3+0>
=> 0x0000000052e6aed4 <+36>:	ld      r2,40(r1)
   0x0000000052e6aed8 <+40>:	mr      r0,r3
   0x0000000052e6aedc <+44>:	std     r0,120(r31)
   0x0000000052e6aee0 <+48>:	ld      r0,120(r31)
   0x0000000052e6aee4 <+52>:	cmpdi   cr7,r0,0
   0x0000000052e6aee8 <+56>:	bne     cr7,0x52e6aef4 <mdb_env_create+68>
   0x0000000052e6aeec <+60>:	li      r0,12
   0x0000000052e6aef0 <+64>:	b       0x52e6afb0 <mdb_env_create+256>
   0x0000000052e6aef4 <+68>:	ld      r0,120(r31)
   0x0000000052e6aef8 <+72>:	li      r9,126
   0x0000000052e6aefc <+76>:	mr      r11,r0
   0x0000000052e6af00 <+80>:	stw     r9,24(r11)
   0x0000000052e6af04 <+84>:	ld      r0,120(r31)
   0x0000000052e6af08 <+88>:	li      r9,2
   0x0000000052e6af0c <+92>:	mr      r11,r0
   0x0000000052e6af10 <+96>:	stw     r9,32(r11)
   0x0000000052e6af14 <+100>:	ld      r0,120(r31)
   0x0000000052e6af18 <+104>:	mr      r9,r0
   0x0000000052e6af1c <+108>:	lwz     r0,32(r9)
   0x0000000052e6af20 <+112>:	clrldi  r9,r0,32
   0x0000000052e6af24 <+116>:	ld      r0,120(r31)
   0x0000000052e6af28 <+120>:	mr      r11,r0
   0x0000000052e6af2c <+124>:	stw     r9,36(r11)
   0x0000000052e6af30 <+128>:	ld      r0,120(r31)
   0x0000000052e6af34 <+132>:	li      r9,-1
   0x0000000052e6af38 <+136>:	mr      r11,r0
   0x0000000052e6af3c <+140>:	stw     r9,0(r11)
   0x0000000052e6af40 <+144>:	ld      r0,120(r31)
   0x0000000052e6af44 <+148>:	li      r9,-1
   0x0000000052e6af48 <+152>:	mr      r11,r0
   0x0000000052e6af4c <+156>:	stw     r9,4(r11)
   0x0000000052e6af50 <+160>:	ld      r0,120(r31)
   0x0000000052e6af54 <+164>:	li      r9,-1
   0x0000000052e6af58 <+168>:	mr      r11,r0
   0x0000000052e6af5c <+172>:	stw     r9,8(r11)
   0x0000000052e6af60 <+176>:	bl      0x52e6a578 <0000088e.plt_call.getpid@@GLIBC_2.3+0>
   0x0000000052e6af64 <+180>:	ld      r2,40(r1)
   0x0000000052e6af68 <+184>:	mr      r0,r3
   0x0000000052e6af6c <+188>:	mr      r9,r0
   0x0000000052e6af70 <+192>:	ld      r0,120(r31)
   0x0000000052e6af74 <+196>:	mr      r11,r0
   0x0000000052e6af78 <+200>:	stw     r9,40(r11)
   0x0000000052e6af7c <+204>:	li      r3,30
...

Comment 8 Jan Synacek 2015-03-19 12:28:08 UTC
Assigning back to openldap. I reproduced this on the latest upstream version and it seems that one of the previous merges of liblmdb is to blame.

Comment 9 Jakub Jelinek 2015-03-19 14:17:45 UTC
If it crashes on that instruction, than supposedly r2 (aka TOC register?) contains a bogus value?  The TOC should be set in the caller of mdb_env_create, perhaps in the plt sequence for it, etc., depending on how it has been called.

Comment 10 Jan Synacek 2015-03-20 13:39:06 UTC
I found out the source of the crash. The problem is, that the mdb_* functions use a gcc attribute that is defined like so:

#  define     ESECT   __attribute__ ((section("text_env")))

Then the functions are defined as, for example, "int ESECT mdb_env_create...". Simply removing the ESECT works. Note that I don't know why the attribute is used like that.

Jakub, any idea why the attribute makes the code crash on ppc64?

Comment 13 Jakub Jelinek 2015-03-25 10:01:24 UTC
(In reply to Jan Synacek from comment #10)
> I found out the source of the crash. The problem is, that the mdb_*
> functions use a gcc attribute that is defined like so:
> 
> #  define     ESECT   __attribute__ ((section("text_env")))
> 
> Then the functions are defined as, for example, "int ESECT
> mdb_env_create...". Simply removing the ESECT works. Note that I don't know
> why the attribute is used like that.
> 
> Jakub, any idea why the attribute makes the code crash on ppc64?

No, you'd need to provide small self-contained testcase so that it could be analyzed.
Bet it was done to improve code locality or something similar.

Comment 16 errata-xmlrpc 2015-07-22 06:18:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1292.html


Note You need to log in before you can comment on or make changes to this bug.