On 11/10/2017 10:17 AM, Tomáš Chvátal wrote:
2017-11-06 9:58 GMT+01:00 Stephan Bergmann <sberg...@redhat.com
<mailto:sberg...@redhat.com>>:
Looking at the surrounding code
// Get redline info.
boost::property_tree::ptree aTree;
char* pJSON =
pDocument->m_pDocumentClass->getCommandValues(pDocument,
".uno:AcceptTrackedChanges");
std::stringstream aStream(pJSON);
free(pJSON);
CPPUNIT_ASSERT(!aStream.str().empty());
boost::property_tree::read_json(aStream, aTree);
// Make sure that pressing a key creates exactly one redline.
CPPUNIT_ASSERT_EQUAL(static_cast<size_t>(1),
aTree.get_child("redlines").size());
what's the binary content of that "char* pJSON" stream? If that's
still intact, then it's apparently boost::property_tree::read_json
that's breaking things. And if that's already garbled, then it's
apparently the producer side of that
pDocument->m_pDocumentClass->getCommandValues (whatever that is)
that is breaking it and needs further investigation.
I checked the read_json function and it was indeed rewritten in between
the boost versions on the distro (and there were some comments about
unicode support). So I had updated the boost function (basically to use
latest boost code) in my testing repo and it still fails:
[ 6427s]
/home/abuild/rpmbuild/BUILD/libreoffice-5.4.2.2/desktop/qa/desktop_lib/test_desktop_lib.cxx:1660:DesktopLOKTest::testRedlineWriter
[ 6427s] equality assertion failed
[ 6427s] - Expected: Insert “t”
[ 6427s] - Actual : Insert “tâ€
FWIW I enabled it on the OBS so the full build log is tracked here:
https://build.opensuse.org/package/live_build_log/LibreOffice:Factory/libreoffice/openSUSE_Leap_42.3/x86_64
Any idea how to check the getCommandValues behaviour if it is the proper
one?
so, again, "what's the binary content of that "char* pJSON" stream?"
can't you just dump it in gdb?
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
