Hi, I'm posting here to discuss a curious bug that I'm not sure of who to blame for ;-).
I have an Aladdin eToken PRO (USB, product id reported by /proc/bus/usb/devices is 0600) which I'm using on Mac OS X. The drivers for this device can be obtained from Aladdin's Russian website[1]. 1. http://www.aladdin.ru/bitrix/redirect.php?event1=download&goto=/upload/iblock/973/PKI_3_65_Mac.zip The package contains a pkcs11 module that can be used with openssl and/or pkcs11-tool. But the command pkcs11-tool --module /usr/local/lib/libetpkcs11.so -L ends in a segmentation fault (regardless of whether the token is inserted or not). Closer inspection of the problem reveals that the program works correctly, and the crash happens after the module is unloaded at the end of the program, even after main() is finished, in the exit routine. Running the same command in gdb results in the following: (gdb) run Starting program: /Library/OpenSC/bin/pkcs11-tool --module libetpkcs11.so -L Reading symbols for shared libraries ......++.++ done Reading symbols for shared libraries ............................................................. done Reading symbols for shared libraries . done Available slots: Slot 0 (empty) Slot 1 (empty) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x01060ce4 0x01060ce4 in AKS::LockedGlobalSingleton1<AKS::MTLock, std::string>::~LockedGlobalSingleton1 () Now my C++ is not that good, but the last line looks like a destructor. The class name (AKS) would suggest that this is Aladdin Knowledge Systems class. It doesn't surprise me that the address is invalid at this point; after all, the module is unloaded from memory. What does surprise me is that some C++ object survived long enough to want to invoke its destructor at the end of the program. A simple experiment to skip the dlclose() call showed that indeed, closing the module is what triggers this problem. The same command works under Linux and Cygwin without crashing. Here is the hundred dollar question: who is to blame, and what did he do wrong? With regards, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.vl-e.nl Phone +31 20 592 50 12 :: http://www.nikhef.nl/~dennisvd/ _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
