Threaded use of smartPtr has issues

[vincent-richard]

I get a SEGFAULT when sending email asynchronously, but only sometimes. This wasn't a problem on a single core CPU, but is on a multi-code CPU.

0 0x00412996 in vmime::utility::refCounter::operator long at utility_smartPtr.cpp:158

1 0x004129ca in vmime::utility::refManager::addStrong at utility_smartPtr.cpp:47

2 0x004404a4 in _ZN5vmime7utility3refINS_8platform7handlerEEcvNS1_IT_EEIKS3_EEv [inlined] at smartPtr.hpp:251

3 0x004404a4 in vmime::platform::getHandler at platform.hpp:143

4 0x004404a4 in vmime::net::smtp::SMTPResponse::readResponseLine at smartPtr.hpp:149

5 0x0044099a in vmime::net::smtp::SMTPResponse::getNextResponse at net_smtp_SMTPResponse.cpp:160

6 0x00441374 in vmime::net::smtp::SMTPResponse::readResponse at net_smtp_SMTPResponse.cpp:96

7 0x00441a68 in vmime::net::smtp::SMTPResponse::readResponse at net_smtp_SMTPResponse.cpp:88

8 0x00443f1d in ~ref [inlined] at net_smtp_SMTPTransport.cpp:622

9 0x00443f1d in ~ref [inlined] at smartPtr.hpp:175

10 0x00443f1d in vmime::net::smtp::SMTPTransport::readResponse at net_smtp_SMTPTransport.cpp:622

11 0x004465cc in attachvmime::net::smtp::SMTPResponse [inlined] at net_smtp_SMTPTransport.cpp:196

12 0x004465cc in vmime::utility::refvmime::net::smtp::SMTPResponse::operator= at smartPtr.hpp:286

13 0x004465cc in vmime::net::smtp::SMTPTransport::helo at net_smtp_SMTPTransport.cpp:196

14 0x004476cb in vmime::net::smtp::SMTPTransport::connect at net_smtp_SMTPTransport.cpp:138

The problem appears to be that the refManager is null:

(gdb) p *platform::sm_handler.m_ptr $9 = {vmime::object = {_vptr$object = 0x5c0258, m_refMgr = 0x0}, }

[nfranke]

This was my bug from sourceforge. I see we've moved. Anything I can do to help resolve this?

[vincent-richard]

A good solution would be using boost library's "shared_ptr" which is largely better than my implementation (and non-intrusive) , but it would involve a large (and non-optional) dependency.

[nfranke]

Maybe you could make it a configure option that #defines a macro that uses one or the other? We'd like to get a solution to this. Would it help if we bought a license?

[vincent-richard]

On which platform are you? If you are on Linux/POSIX, ensure VMime is compiled with pthread support (VMIME_HAVE_PTHREAD).

[nfranke]

Sorry this took so long. I noticed that I had an old vmime header in the include path. While the library was compiled with VMIME_HAVE_PTHREAD, the old header didn't have VMIME_HAVE_PTHREAD set. When I removed that, it seems to be stable so far.