Bug 67909

Created attachment 83853 [details]
Dbus Full Session Dump

Created attachment 83854 [details]
sync.py output dump

The relevant logic which checks for new data is here:

bool PullAll::getContact(int contactNumber, pcrecpp::StringPiece &vcard)
{
    SE_LOG_DEBUG(NULL, "get PBAP contact #%d", contactNumber);
    if (contactNumber < 0 ||
        contactNumber >= m_numContacts) {
        SE_LOG_DEBUG(NULL, "invalid contact number");
        return false;
    }

    Content::iterator it;
    while ((it = m_content.find(contactNumber)) == m_content.end() &&
           m_session &&
           (!m_session->transferComplete() ||
            m_tmpFile.moreData())) {
        // Wait? We rely on regular propgress signals to wake us up.
        // obex 0.47 sends them every 64KB, at least in combination
        // with a Samsung Galaxy SIII. This may depend on both obexd
        // and the phone, so better check ourselves and perhaps do it
        // less often - unmap/map can be expensive and invalidates
        // some of the unread data (at least how it is implemented
        // now).
        while (!m_session->transferComplete() && m_tmpFile.moreData() < 128 * 1024) {
            g_main_context_iteration(NULL, true);
        }
        m_session->checkForError();
        if (m_tmpFile.moreData()) {
            // Remap. This shifts all addresses already stored in
            // m_content, so beware and update those.
            pcrecpp::StringPiece oldMem = m_tmpFile.stringPiece();
            m_tmpFile.unmap();
            m_tmpFile.map();
            pcrecpp::StringPiece newMem = m_tmpFile.stringPiece();
            ssize_t delta = newMem.data() - oldMem.data();
            BOOST_FOREACH (Content::value_type &entry, m_content) {
                pcrecpp::StringPiece &vcard = entry.second;
                vcard.set(vcard.data() + delta, vcard.size());
            }

            // File exists and obexd has written into it, so now we
            // can unlink it to avoid leaking it if we crash.
            m_tmpFile.remove();

            // Continue parsing where we stopped before.
            pcrecpp::StringPiece next(newMem.data() + m_tmpFileOffset,
                                      newMem.size() - m_tmpFileOffset);
            const char *end = addVCards(m_content.size(), next);
            int newTmpFileOffset = end - newMem.data();
            SE_LOG_DEBUG(NULL, "PBAP content parsed: %d out of %d (total), %d out of %d (last update)",
                         newTmpFileOffset,
                         newMem.size(),
                         (int)(end - next.data()),
                         next.size());
            m_tmpFileOffset = newTmpFileOffset;
        }
    }

    if (it == m_content.end()) {
        SE_LOG_DEBUG(NULL, "did not get the expected contact #%d, perhaps some contacts were deleted?", contactNumber);
        return false;
    }
    vcard = it->second;
    return true;
}

I see org.freedesktop.DBus.Properties.PropertiesChanged signals in the D-Bus log, which should wake up SyncEvolution and cause it to check the file size. In other words, I it is not obvious why it doesn't read more contacts from the file.

Can I get a syncevolution-log.html file of the target side with loglevel=4?

I was able to reproduce the problem. Expect a patch soon.

Created attachment 83893 [details] [review]
ignore Status=active instead of terminating when seeing it

This patch fixes the problem for me.

It seems fixed also here.
I'll try to perform in any case some more tests.
Thanks.