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