Aki Tuomi
2016-Oct-26 12:29 UTC
(build) crash in dcrypt when "-Bsymbolic-functions" is used on linking
On 26.10.2016 13:48, Christian Ehrhardt wrote:> Hi, > I was wondering about a crash when building dovecot 2.2.25 on latest > Ubuntu. > I wondered as I've had the same source building on Debian just fine. > > Some debugging led me to this weird behavior: > Using this gdb command file called autoreportissue in my case: > break dcrypt_initialize > commands > p dcrypt_vfs > p &dcrypt_vfs > watch dcrypt_vfs > c > end > break dcrypt_set_vfs > commands > p dcrypt_vfs > p &dcrypt_vfs > c > end > r > > Running test-crypto on Debian and Ubuntu reported those two behaviours: > gdb -d /root/dovecot-2.2.25/src/ -x autoreportissue ./test-crypto > > Good: > Breakpoint 1, dcrypt_initialize (backend=0x555555587c02 "openssl", > set=0x0, error_r=0x0) at dcrypt.c:15 > 15 if (dcrypt_vfs != NULL) { > $1 = (struct dcrypt_vfs *) 0x0 > $2 = (struct dcrypt_vfs **) 0x555555796370 <dcrypt_vfs> > Hardware watchpoint 3: dcrypt_vfs > Breakpoint 2, dcrypt_set_vfs (vfs=0x7ffff7835020 <dcrypt_openssl_vfs>) > at dcrypt.c:56 > 56 dcrypt_vfs = vfs; > $3 = (struct dcrypt_vfs *) 0x0 > $4 = (struct dcrypt_vfs **) 0x555555796370 <dcrypt_vfs> > Hardware watchpoint 3: dcrypt_vfs > Old value = (struct dcrypt_vfs *) 0x0 > New value = (struct dcrypt_vfs *) 0x7ffff7835020 <dcrypt_openssl_vfs> > dcrypt_set_vfs (vfs=0x7ffff7835020 <dcrypt_openssl_vfs>) at dcrypt.c:57 > 57 } > > Bad: > Breakpoint 1, dcrypt_initialize (backend=0x555555589f02 "openssl", > set=0x0, error_r=0x0) at dcrypt.c:11 > 11 { > $1 = (struct dcrypt_vfs *) 0x0 > $2 = (struct dcrypt_vfs **) 0x555555798370 <dcrypt_vfs> > Hardware watchpoint 3: dcrypt_vfs > Breakpoint 2, dcrypt_set_vfs (vfs=0x7ffff780a020 <dcrypt_openssl_vfs>) > at dcrypt.c:56 > 56 dcrypt_vfs = vfs; > $3 = (struct dcrypt_vfs *) 0x0 > $4 = (struct dcrypt_vfs **) 0x7ffff780a890 <dcrypt_vfs> > Panic: file dcrypt.c: line 34 (dcrypt_initialize): assertion failed: > (dcrypt_vfs != NULL) > Error: Raw backtrace: > /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(+0x15f7c) > [0x555555569f7c] -> > /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(default_error_handler+0) > [0x55555556a030] -> > /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(i_fatal+0) > [0x55555556a2ff] -> > /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(dcrypt_initialize+0x140) > [0x55555555f030] -> > /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(main+0x23) > [0x55555556706d] -> > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) > [0x7ffff782d3f1] -> > /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(_start+0x2a) > [0x55555555edea] > Program received signal SIGABRT, Aborted. > > One can see that in the bad case the pointer of dcrypt_vfs is pointing > to something of the scope of the .libs/libdcrypt_openssl.so file and > not the dcrypt_initialize of test-crypto. > > That made me wonder even more - where would this issue of variable > scope come from. After more debugging I found that the linker flag > "-Bsymbolic-functions" is the reason. This is default on recent > Ubuntu, but not on Debian (?yet?). > > Eventually what happens is that the dcrypt_vfs becomes part of the > .libs/libdcrypt_openssl.so. So the call from there to dcrypt_set_vfs > ends up setting not the expected variable. > I was unable to come up with a reasonable fix since I'm not enough > into your sublib structure. > > For now I assume I'm gonna build the package stripping this flag in > Ubuntu. > But long term I think dovecot should fix it to work with that compiler > flag. > Therefore the report to make you aware. > > > P.S. thanks to the dovecot community for having unit tests that find > this at build time! > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical LtdHi! Thank you for reporting this, we'll look into it. Aki Tuomi Dovecot oy
Aki Tuomi
2016-Nov-25 12:17 UTC
(build) crash in dcrypt when "-Bsymbolic-functions" is used on linking
On 26.10.2016 15:29, Aki Tuomi wrote:> > > On 26.10.2016 13:48, Christian Ehrhardt wrote: >> Hi, >> I was wondering about a crash when building dovecot 2.2.25 on latest >> Ubuntu. >> I wondered as I've had the same source building on Debian just fine. >> >> Some debugging led me to this weird behavior: >> Using this gdb command file called autoreportissue in my case: >> break dcrypt_initialize >> commands >> p dcrypt_vfs >> p &dcrypt_vfs >> watch dcrypt_vfs >> c >> end >> break dcrypt_set_vfs >> commands >> p dcrypt_vfs >> p &dcrypt_vfs >> c >> end >> r >> >> Running test-crypto on Debian and Ubuntu reported those two behaviours: >> gdb -d /root/dovecot-2.2.25/src/ -x autoreportissue ./test-crypto >> >> Good: >> Breakpoint 1, dcrypt_initialize (backend=0x555555587c02 "openssl", >> set=0x0, error_r=0x0) at dcrypt.c:15 >> 15 if (dcrypt_vfs != NULL) { >> $1 = (struct dcrypt_vfs *) 0x0 >> $2 = (struct dcrypt_vfs **) 0x555555796370 <dcrypt_vfs> >> Hardware watchpoint 3: dcrypt_vfs >> Breakpoint 2, dcrypt_set_vfs (vfs=0x7ffff7835020 >> <dcrypt_openssl_vfs>) at dcrypt.c:56 >> 56 dcrypt_vfs = vfs; >> $3 = (struct dcrypt_vfs *) 0x0 >> $4 = (struct dcrypt_vfs **) 0x555555796370 <dcrypt_vfs> >> Hardware watchpoint 3: dcrypt_vfs >> Old value = (struct dcrypt_vfs *) 0x0 >> New value = (struct dcrypt_vfs *) 0x7ffff7835020 <dcrypt_openssl_vfs> >> dcrypt_set_vfs (vfs=0x7ffff7835020 <dcrypt_openssl_vfs>) at dcrypt.c:57 >> 57 } >> >> Bad: >> Breakpoint 1, dcrypt_initialize (backend=0x555555589f02 "openssl", >> set=0x0, error_r=0x0) at dcrypt.c:11 >> 11 { >> $1 = (struct dcrypt_vfs *) 0x0 >> $2 = (struct dcrypt_vfs **) 0x555555798370 <dcrypt_vfs> >> Hardware watchpoint 3: dcrypt_vfs >> Breakpoint 2, dcrypt_set_vfs (vfs=0x7ffff780a020 >> <dcrypt_openssl_vfs>) at dcrypt.c:56 >> 56 dcrypt_vfs = vfs; >> $3 = (struct dcrypt_vfs *) 0x0 >> $4 = (struct dcrypt_vfs **) 0x7ffff780a890 <dcrypt_vfs> >> Panic: file dcrypt.c: line 34 (dcrypt_initialize): assertion failed: >> (dcrypt_vfs != NULL) >> Error: Raw backtrace: >> /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(+0x15f7c) >> [0x555555569f7c] -> >> /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(default_error_handler+0) >> [0x55555556a030] -> >> /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(i_fatal+0) >> [0x55555556a2ff] -> >> /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(dcrypt_initialize+0x140) >> [0x55555555f030] -> >> /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(main+0x23) >> [0x55555556706d] -> >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) >> [0x7ffff782d3f1] -> >> /root/dovecot-2.2.25/src/lib-dcrypt/test-crypto(_start+0x2a) >> [0x55555555edea] >> Program received signal SIGABRT, Aborted. >> >> One can see that in the bad case the pointer of dcrypt_vfs is >> pointing to something of the scope of the .libs/libdcrypt_openssl.so >> file and not the dcrypt_initialize of test-crypto. >> >> That made me wonder even more - where would this issue of variable >> scope come from. After more debugging I found that the linker flag >> "-Bsymbolic-functions" is the reason. This is default on recent >> Ubuntu, but not on Debian (?yet?). >> >> Eventually what happens is that the dcrypt_vfs becomes part of the >> .libs/libdcrypt_openssl.so. So the call from there to dcrypt_set_vfs >> ends up setting not the expected variable. >> I was unable to come up with a reasonable fix since I'm not enough >> into your sublib structure. >> >> For now I assume I'm gonna build the package stripping this flag in >> Ubuntu. >> But long term I think dovecot should fix it to work with that >> compiler flag. >> Therefore the report to make you aware. >> >> >> P.S. thanks to the dovecot community for having unit tests that find >> this at build time! >> >> -- >> Christian Ehrhardt >> Software Engineer, Ubuntu Server >> Canonical Ltd > > > Hi! > > Thank you for reporting this, we'll look into it. > > Aki Tuomi > Dovecot oyHi! We believe this is fixed in 2.2.26, with https://github.com/dovecot/core/commit/452d0005a47c6872590346f5ea8b247974689ac9, can you please retry with -Bsymbolic? Aki