This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [64bit] openldap compilation doesn't produce shared libraries
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 13 Jun 2013 10:19:28 +0200
- Subject: Re: [64bit] openldap compilation doesn't produce shared libraries
- References: <87sj13i801 dot fsf at oracle dot com> <51A8D6C0 dot 3060507 at users dot sourceforge dot net> <51B1945E dot 6060002 at users dot sourceforge dot net> <87obbil3hb dot fsf at VZELL-LAP dot de dot oracle dot com> <87wqq2cotj dot fsf at oracle dot com> <20130610095305 dot GA32691 at calimero dot vinschen dot de> <87bo7ekuaz dot fsf at VZELL-LAP dot de dot oracle dot com> <51B925EC dot 1090706 at users dot sourceforge dot net>
- Reply-to: cygwin-apps at cygwin dot com
On Jun 12 20:52, Yaakov (Cygwin/X) wrote:
> On 2013-06-10 07:46, Dr. Volker Zell wrote:
> >I think the stack trace translates to the following:
> >
> >Stack trace:
> >Frame Function Args
> >ber_get_stringbvl
> >/usr/src/debug/openldap-2.4.35-1/libraries/liblber/decode.c:414
> >ber_scanf
> >/usr/src/debug/openldap-2.4.35-1/libraries/liblber/decode.c:790
> >ldap_get_attribute_ber
> >/usr/src/debug/openldap-2.4.35-1/libraries/libldap/getattr.c:132
> >print_entry
> >/usr/src/debug/openldap-2.4.35-1/clients/tools/ldapsearch.c:1634
> >main
> >/usr/src/debug/openldap-2.4.35-1/clients/tools/ldapsearch.c:1222
> >
> >The offending code line
> > case BvOff:
> > res.bo = (char *) b->result + b->off;
> > ((struct berval *) (res.bo + tot_size))->bv_val = NULL; <- line 414
> > tot_size = 0;
> > break;
>
> That is where it is crashing, but after some debugging, AFAICS the
> real culprit is the call to ber_scanf() in ldap_get_attribute_ber().
> Presumably because this is a varargs function, the compiler wasn't
> able to handle the necessary type promotion automatically (ber_len_t
> is an unsigned long); so b->off was showing here as 0x600000000,
> taking line 414 off to la-la land. Patch attached and pushed to
> Ports git.
Too bad. This is a typical problem of projects which have been ported
to 64 bit, but only to SYSV ABI, not to MS ABI. The problem never shows
up in the SYSV ABI (Linux, Solaris, etc), because arguments < 64 bit are
zero extended when pushed on the stack. Unfortunately, in the MS ABI,
parameters < 64 bit are not zero extended so the higher bits can contain
any random value. Here, the uncasted 0 is int, so it's pushed on the
stack with the higher 32 bit set to any garbage this stack address
contains at the time.
Given our LP64-ness, I'm wondering if we couldn't tweak gcc to zero
extend arguments as well, even when otherwise using the MS ABI...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat