You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue also exists with bench/search. Rebuilding with make CFLAGS=-g allows valgrind to look into the problem. bench/search was more time-tractable with valgrind:
Xiao noted in email that the code is significantly different from the one in published version. While we chase down regressions, I'll try to upload the original version on a separate branch in case it helps anyone.
The text was updated successfully, but these errors were encountered:
Indeed. I was unaware there were updates. Now that I know, I'll wait to merge them in until this issue is resolved. A thought: you and I are both providing libraries that provide ORAM in Obliv-C, and our codebases are mostly-identical. Someday we may want to do some sort of reconciliation between them.
#1
Circuit ORAM had a bug in memory management when data size is large enough for recursion. Bug was possibly introduced during a "clean up" phase that was not properly tested.
The current HEAD is broken on even circuit ORAM tests:
$ make build/test/testOramAccess $ build/test/testOramAccess -- 1234 ckt --auto=512 & $ build/test/testOramAccess localhost 1234 ckt --auto=512 [...stacktrace...]
The issue also exists with
bench/search
. Rebuilding withmake CFLAGS=-g
allows valgrind to look into the problem.bench/search
was more time-tractable with valgrind:$ make CFLAGS=-g build/bench/search $ valgrind build/bench/search bench -t ckt --size=257 --axcount=6 :1234 & $ valgrind build/bench/search bench -t ckt localhost:1234
Logs attached
Xiao noted in email that the code is significantly different from the one in published version. While we chase down regressions, I'll try to upload the original version on a separate branch in case it helps anyone.
The text was updated successfully, but these errors were encountered: