NDN project issue tracking system: Issueshttps://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232020-04-02T13:14:32ZNDN project issue tracking system
Redmine ChronoSync - Bug #5098 (New): LeafTests/LeafDigest fails on s390xhttps://redmine.named-data.net/issues/50982020-04-02T13:14:32ZDavide Pesavento
<pre><code>../tests/unit-tests/test-leaf.cpp(60): error: in "LeafTests/LeafDigest": check result == ndn::toHex(digest->data(), digest->size(), false) has failed [05fe7f728d3341e9eff82526277b02171044124d0a52e8c4610982261c20de2b != 78534cf9d72d77670ca306e3678f7ef9b8cd02dc193798e849c230af8efec9c2]
</code></pre>
<p>This seems to be an endianness bug in the way the digest is calculated. <code>chronosync::Leaf</code> adds the sequence number (a <code>uint64_t</code>) to the digest via ndn-cxx's <code>util::Sha256</code> class, which uses the host endianness to compute the hash of a <code>uint64_t</code> and is therefore not portable. To be fair, <code>uint64_t</code> support in <code>util::Sha256</code> is probably ill-designed, or its documentation should at least state that it's not endian-safe and thus the result is not suitable for network protocols.</p>
ChronoSync - Bug #4525 (New): Destructing a ChronoSync socket object shuts down the facehttps://redmine.named-data.net/issues/45252018-03-02T10:33:42ZNicholas Gordonnmgordon@memphis.edu
<p>Currently the ChronoSync socket class accepts a reference to a Face object. I think this is intended to support using one face for multiple different applications. However, when destructing the Logic class, the face is shutdown. This means that the face object becomes unusable, defeating the point of it being a reference.</p>
<p>I see two paths forward: ChronoSync should create a separate face and use that one to avoid conflicts when shutting the face down, or clean up after itself correctly, meaning: cancel pending interests and un-register prefixes. Logic only sends interests, so remembering pending interests would be the only necessary step.</p>
ChronoSync - Bug #4495 (New): Strange buffer overflow / random crash of chronosync::Socket relate...https://redmine.named-data.net/issues/44952018-02-08T11:05:16ZAlex Afanasyev
<p>The following snippet suppose to work without problems</p>
<p>test.cpp:</p>
<pre><code>#include <iostream>
#include <sstream>
#include <unordered_map>
#include <memory>
#include <ndn-cxx/face.hpp>
#include <ndn-cxx/name.hpp>
#include <ndn-cxx/security/key-chain.hpp>
#include <ChronoSync/socket.hpp>
#include <boost/asio.hpp>
int
main()
{
using namespace ndn;
KeyChain keychain;
boost::asio::io_service io;
Face face(nullptr, io, keychain);
auto socket3 = std::make_shared<chronosync::Socket>("/test/sync2", "/test/user2",
face,
[] (const std::vector<chronosync::MissingDataInfo>& info) {
std::cerr << "Update" << std::endl;
},
Name("/hello"),
nullptr,
ndn::time::seconds(60));
face.processEvents();
}
</code></pre><pre><code>g++ -std=c++11 `pkg-config --cflags libndn-cxx` `pkg-config --cflags ChronoSync` test.cpp `pkg-config --libs libndn-cxx` `pkg-config --libs ChronoSync` -fsanitize=address
</code></pre>
<p>However, when ndn-cxx compiled <code>--with-sanitizer=address</code>, it results in a stable crash</p>
<pre><code>./a.out
</code></pre><pre><code>==13619==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x620000001fe0 at pc 0x00011143d118 bp 0x7ffee0077310 sp 0x7ffee0076ac0
WRITE of size 64 at 0x620000001fe0 thread T0
#0 0x11143d117 in __asan_memset (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x51117)
#1 0x10fcfa7f1 in ndn::InMemoryStorage::InMemoryStorage(unsigned long) deque:1094
#2 0x10fcfa104 in ndn::InMemoryStoragePersistent::InMemoryStoragePersistent() in-memory-storage-persistent.cpp:27
#3 0x11129a72c in chronosync::Socket::Socket(ndn::Name const&, ndn::Name const&, ndn::Face&, std::__1::function<void (std::__1::vector<chronosync::MissingDataInfo, std::__1::allocator<chronosync::MissingDataInfo> > const&)> const&, ndn::Name const&, std::__1::shared_ptr<ndn::security::v2::Validator>, boost::chrono::duration<long long, boost::ratio<1l, 1000l> > const&) socket.cpp:36
#4 0x10fb9a9f7 in std::__1::shared_ptr<chronosync::Socket> std::__1::shared_ptr<chronosync::Socket>::make_shared<char const (&) [12], char const (&) [12], ndn::Face&, main::$_0, ndn::Name, std::nullptr_t, boost::chrono::duration<long long, boost::ratio<1l, 1l> > >(char const (&&&) [12], char const (&&&) [12], ndn::Face&&&, main::$_0&&, ndn::Name&&, std::nullptr_t&&, boost::chrono::duration<long long, boost::ratio<1l, 1l> >&&) (ndn-proxy:x86_64+0x1000159f7)
#5 0x10fb8c57a in main (ndn-proxy:x86_64+0x10000757a)
#6 0x7fff59c6f114 in start (libdyld.dylib:x86_64+0x1114)
0x620000001fe0 is located 0 bytes to the right of 3936-byte region [0x620000001080,0x620000001fe0)
allocated by thread T0 here:
#0 0x1114500ab in wrap__Znwm (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x640ab)
#1 0x10fb98d1f in std::__1::shared_ptr<chronosync::Socket> std::__1::shared_ptr<chronosync::Socket>::make_shared<char const (&) [12], char const (&) [12], ndn::Face&, main::$_0, ndn::Name, std::nullptr_t, boost::chrono::duration<long long, boost::ratio<1l, 1l> > >(char const (&&&) [12], char const (&&&) [12], ndn::Face&&&, main::$_0&&, ndn::Name&&, std::nullptr_t&&, boost::chrono::duration<long long, boost::ratio<1l, 1l> >&&) (ndn-proxy:x86_64+0x100013d1f)
#2 0x10fb8c57a in main (ndn-proxy:x86_64+0x10000757a)
#3 0x7fff59c6f114 in start (libdyld.dylib:x86_64+0x1114)
SUMMARY: AddressSanitizer: heap-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x51117) in __asan_memset
Shadow bytes around the buggy address:
0x1c40000003a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c40000003b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c40000003c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c40000003d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c40000003e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1c40000003f0: 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa
0x1c4000000400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c4000000410: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c4000000420: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c4000000430: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c4000000440: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==13619==ABORTING
Abort trap: 6
</code></pre>
<p>Changing std::deque to std::list/vector, resolves the problem, but I'm really puzzled of what is going on.</p>
ChronoShare - Task #3952 (Resolved): Restore routable prefix discovery in Dispatcher modulehttps://redmine.named-data.net/issues/39522017-02-07T16:58:25ZAlex AfanasyevChronoShare - Task #3926 (New): Avoid all uses of boost::posix_time with ndn::time (boost::chrono)https://redmine.named-data.net/issues/39262017-01-15T14:36:51ZAlex Afanasyev
<p>In part, this is a requirement for unit-testing</p>
ChronoShare - Task #3925 (New): Avoid creation multiple instances of KeyChainhttps://redmine.named-data.net/issues/39252017-01-13T16:10:38ZAlex Afanasyev
<p>KeyChain instance should be created only once (somewhere around main function) and passed everywhere else via reference.</p>
ChronoSync - Bug #3885 (New): processSyncInterest: Interest for new data getting satisfied by cac...https://redmine.named-data.net/issues/38852016-12-11T13:54:45ZSonu Mishra
<p>Suppose a node x sends an interest with a digest that another node y does not recognize. When node y receives this interest, it sends its full old data as a reply. When node x receives this old data, it discards it -- as it finds nothing new in the data -- and resends the interest. The problem is that the old data gets cached and it keeps satisfying the interest. The interest does not travel to another node z that has the relevant new data, causing unnecessary delays.</p>
<p>Therefore, sending of old data in reply to interest with unrecognized digest is a bug that needs to be fixed.</p>
ChronoSync - Task #3883 (New): Time gap between interest expiration and refreshhttps://redmine.named-data.net/issues/38832016-12-11T13:27:19ZSonu Mishra
<p>The synchronization delay is high when the sync interest lifetime value is small. One of the reasons for poorer performance is the time gap between interest expiration and the arrival of next refresh interests. When the sync interest lifetime value is small, the chances of the interest expiring right before the data generation increases. This leads to higher synchronization delay. </p>
ChronoChat - Bug #3719 (New): NfdConnectionChecker: does not process Nackhttps://redmine.named-data.net/issues/37192016-08-04T22:57:39ZJunxiao Shi
<p><code>chronochat::NfdConnectionChecker::run</code> is using a deprecated overload of <code>Face::expressInterest</code> that does not process Nack.</p>
ChronoChat - Bug #3718 (New): ControllerBackend: does not process Nackhttps://redmine.named-data.net/issues/37182016-08-04T22:57:37ZJunxiao Shi
<p><code>chronochat::ContactManager::fetchEndorseCertificateInternal</code> and <code>chronochat::ContactManager::sendInterest</code> are using a deprecated overload of <code>Face::expressInterest</code> that does not process Nack.</p>
ChronoChat - Bug #3717 (New): ControllerBackend: does not process Nackhttps://redmine.named-data.net/issues/37172016-08-04T22:57:35ZJunxiao Shi
<p><code>chronochat::ControllerBackend::onRequestTimeout</code> and <code>chronochat::ControllerBackend::onSendInvitationRequest</code> are using a deprecated overload of <code>Face::expressInterest</code> that does not process Nack.</p>
ChronoChat - Feature #3405 (New): nfd-androidhttps://redmine.named-data.net/issues/34052016-01-11T10:47:40ZHARSHIT SINGHharsh0233@gmail.com
<p>how to connect two android devices using nfd-android</p>
ChronoChat - Task #2539 (New): Re-license code to GPL 3+https://redmine.named-data.net/issues/25392015-02-18T16:02:24ZAlex Afanasyev
<p>To be consistent with licensing, we should change ChronoChat license to GPL 3+</p>
ChronoChat - Task #2487 (Code review): Use user's default identity as the initial identity https://redmine.named-data.net/issues/24872015-02-06T15:13:26ZYingdi Yuyuyingdi@gmail.com
<p>For now we always use some tmp id even if the default identity is available, also we need to pop up a warning dialog to notify people "temp id is used!"</p>
ChronoChat - Bug #2485 (New): All other participants "leaves room" when adjusting clockhttps://redmine.named-data.net/issues/24852015-02-06T12:33:38ZJunxiao Shi
<p>Steps to reproduce:</p>
<ol>
<li>set system clock to 10 minutes behind NTP time</li>
<li>join a chatroom with some other participants</li>
<li>set system clock to NTP time (10 minutes forward from previous setting)</li>
</ol>
<p>Expected: all participants are still in the room<br><br>
Actual: all participants disappear with "leaves room" message</p>