This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [64bit] openldap compilation doesn't produce shared libraries


>>>>> Corinna Vinschen writes:

    > On Jun 10 11:11, Dr. Volker Zell wrote:
    >> >>>>> Volker Zell writes:
    >> 
    >> >>>>> Yaakov  writes:
    >> >> Following up on this, I noticed that slapd's build process is quite broken,
    >> >> resulting in an invalidly formatted executable.  The working method to create a
    >> >> linkable EXE is to just link it with
    >> >> -Wl,--export-all-symbols,--out-implib,libfoo.a, then link other modules with
    >> >> -Wl,path/to/libfoo.a.  (Relying on -L flags for in-tree paths isn't always a
    >> >> good idea with libtool.)
    >> 
    >> >> I took the liberty of fixing up the build of slapd both with and without modular
    >> >> backends/overlays.  The patch and modified cygport(3) are in Ports git:
    >> 
    >> >> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/openldap
    >> 
    >> > You made my day. I am struggling with this since more than a week. I
    >> > actually managed to get a working slapd executable but the openldap test
    >> > suite still doesn't run. ldapsearch always core dumps. I will check out
    >> > your .cygport approach and see if it makes any difference. I'll try to
    >> > do it on monday...
    >> 
    >> Building with your cygport file also results in ldapsearch core dumping :-(
    >> 
    >> Running with strace gives:
    >> 
    >> ldapsearch.exe.stackdump:
    >> 
    >> Exception: STATUS_ACCESS_VIOLATION at rip=004091D184A
    >> [...]
    >> Stack trace:
    >> Frame        Function    Args
    >> 00000229D70  004091D184A (00000229DC0, 0000000036E, 006000424CD, 00000000374)
    >> 00000229D70  004091D22F2 (00000000000, 00000229F70, 00000229F40, 00000229E18)

    > These addresses are in some DLL.  Check the installed DLLs with 
    > `rebase -i /bin/*.dll' and the not-installed DLLs with objdump -h for their
    > addresses to find out which one this is.

    >> 00000229F40  005205B287C (00600040E60, 00000000000, 001800C0C93, 00000229F40)

    > Another DLL.

    >> 00600042160  00100401DDB (0000038F194, 001802DFFDD, 00000000000, 0010040F4ED)
    >> 00000000000  0010040BD69 (0000022AB80, 00000000000, 00000000000, 00000000000)

    > The executable itself, probably main and another function called from main.

    >> 0000022AB80  001800483AE (00000000000, 00000000000, 00000000000, 00000000000)
    >> 00000000000  0018004618B (00000000000, 00000000000, 00000000000, 00000000000)
    >> 00000000000  0018004634F (00000000000, 00000000000, 00000000000, 00000000000)

    > Cygwin DLL, probably the normal startup via dll_crt0_1.

    >> 00000000000  0010040A4C1 (00000000000, 00000000000, 00000000000, 00000000000)
    >> 00000000000  00100401010 (00000000000, 00000000000, 00000000000, 00000000000)
    >> 00000000000  0007740652D (00000000000, 00000000000, 00000000000, 00077489300)
    >> 00000000000  00077AFC521 (00000000000, 00000000000, 00000000000, 00077489300)

    > This is the normal start up of the executable.

    > As for the addresses, I'd like to point out my mail from February again:
    > http://cygwin.com/ml/cygwin-developers/2013-02/msg00027.html
    > Maybe that should go into the user's guide at one point.

    >> The strace output is attached.

    > See below.

    >> Running under gdb doesn't work either. What am I doing wrong here ?

    > Did you build the entire stuff, including the libs, without optimization?
    > That helps a lot when debugging.

    >> vzell@leila /cygdrive/d/misc/src/release64/openldap-2.4.35-1/build/tests
    >> 10:40 AM [519]> PATH=../../inst/usr/lib/debug/usr/bin:$PATH gdb ../../inst/usr/lib/debug/usr/bin/ldapsearch.exe.dbg

    > You cannot start the *.dbg file.  It's just the file containing the
    > debug symbols, not the actual binary.  What you should do is starting
    > the real binary:

    >   $ gdb ./ldapsearch.exe

    > and then, if gdb complains that it can't find the debug symbols:

    >   (gdb) symbol-file ../../inst/usr/lib/debug/usr/bin/ldapsearch.exe.dbg

    >> [...]
    >> 43   89818 [main] ldapsearch 5512 fhandler_base::fstat_helper: 0 = fstat (\??\D:\misc\src\release64\openldap-2.4.35-1\build\tests\STARCE, 0x229C20) st_size=137414, st_mode=0x81A4, st_ino=15199648742446005st_atim=51B5931C.1BF62654 st_ctim=51B5931C.1BF62654 st_mtim=51B5931C.1BF62654 st_birthtim=51B5931C.1BF62654
    >> 24   89842 [main] ldapsearch 5512 fstat64: 0 = fstat(1, 0x229C20)
    >> --- Process 1028, exception c0000005 at 00000004091D184A

    > I don't know what's causing this, but this very certainly occurs
    > inside of the DLL located at or around 0x4:091d0000, after a call
    > to fstat for the file STARCE.


Via similar calls (see one line below) to ldapsearch.exe and the not yet installed openldap libraries

   awk '/^[0-9]/{print $2}' ldapsearch.exe.stackdump | addr2line -f -e ../libraries/liblber/.libs/cyglber-2-4-2.dll
   awk '/^[0-9]/{print $2}' ldapsearch.exe.stackdump | addr2line -f -e ../libraries/libldap/.libs/cygldap-2-4-2.dll
   awk '/^[0-9]/{print $2}' ldapsearch.exe.stackdump | addr2line -f -e ../clients/tools/.libs/ldapsearch.exe
   
I think the stack trace


Stack trace:
Frame        Function    Args
00000229D70  004091D184A (00000229DC0, 0000000036E, 0060001A2FD, 00000000374)
00000229D70  004091D22F2 (00000000000, 00000229F70, 00000229F40, 00000229E18)
00000229F40  005205B287C (00600018C90, 00000000000, 001800C0C93, 00000229F40)
00600019F90  00100401DDB (0000026F194, 001802E98E5, 00000000023, 0010040F4ED)
00000000000  0010040BD69 (001802E6C10, 001802EA678, 00180067091, 0000022AB80)
0000022AB80  001800483AE (00000000000, 00000000000, 00000000000, 00000000000)
00000000000  0018004618B (00000000000, 00000000000, 00000000000, 00000000000)
00000000000  0018004634F (00000000000, 00000000000, 00000000000, 00000000000)
00000000000  0010040A4C1 (00000000000, 00000000000, 00000000000, 00000000000)
00000000000  00100401010 (00000000000, 00000000000, 00000000000, 00000000000)
00000000000  00076CC652D (00000000000, 00000000000, 00000000000, 00076D49300)
00000000000  000772BC521 (00000000000, 00000000000, 00000000000, 00076D49300)
End of 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
0000022AB80  001800483AE (00000000000, 00000000000, 00000000000, 00000000000)   <- cygwin dll
00000000000  0018004618B (00000000000, 00000000000, 00000000000, 00000000000)   <- cygwin dll
00000000000  0018004634F (00000000000, 00000000000, 00000000000, 00000000000)   <- cygwin dll
cygwin_crt0
/usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/lib/cygwin_crt0.c:22
mainCRTStartup
/usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/crt0.c:34
00000000000  00076CC652D (00000000000, 00000000000, 00000000000, 00076D49300)
00000000000  000772BC521 (00000000000, 00000000000, 00000000000, 00076D49300)
End of stack trace


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;


If anybody can help with this, it would be much appreciated.

    > Corinna

Ciao
  Volker
  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]