On Fri, Jan 24, 2003 at 10:54:54AM -0600, Steve Greenland scribbled: [snip] > > but aren't Linux threads implemented as > > full-blown processes? > > Kind of... > > > Which means they get their own heap space, so malloc()'d areas > > wouldn't be shared. > > No. There's a special flag in the clone(2) call used for thread creation > that causes the new "process" to share VM. If they didn't, they'd hardly > be threads. Yep, actually, the only problem with threads is when you want to have thread-private storage, then you have to do magic things to make that work :) - the reverse of my situation. Actually, I have found (sort of) the cause of the problem. It was the fact that libesmtp (used by the daemon) had the program linked with two versions of libssl and libcrypto. libesmtp-config --libs tells the application to add -lssl and -lcrypto to the command line and that pulled in the 0.9.7 version of the libraries while the libesmtp.so was linked against 0.9.6 (both in /usr/lib/i686). As soon as I relinked the program without using -lssl -lcrypto on its command line, it started to work. But that's not the end yet:). Today when I restarted the machine and tried to link the daemon in the same way as originally, with two versions of the libs linked in, the error from yesterday didn't come back (and the code wasn't touched since yesterday...). So, I guess, it must've been an accident after upgrading to new libc version without rebooting afterwards and the doubly linked libraries. regards, marek
Attachment:
pgpFlkG_CGH_b.pgp
Description: PGP signature