Month: August 2017

The timezone issue of installing OpenBSD in VirtualBox

I tried to use OpenBSD in VirtualBox. During installation, it prompted me:

Time appears wrong. Set to ‘Sat Aug 19 11:56:42 +08 2017’? [yes]

Since my server is UTC+8 timezone, I select “yes”. But after rebooting, the date command showed wrong info:

#date
Sat Aug 19 20:01:00 +8 2017
#date
Sat Aug 19 12:01:05 UTC 2017

Actually, my current host time should be 12:01:05 UTC+8. The VirtualBox seemed consider the host time as UTC time, and added another 8 hours. After discussing in the mailing list, the correct answer was found. I should tick “Hardware clock in UTC time” in setting:

Capture

According the manual:

If checked, VirtualBox will report the system time in UTC format to the guest instead of local (host) time. This affects how the virtual real-time clock (RTC) operates and may be useful for Unix-like guest operating systems, which typically expect the hardware clock to be set to UTC.

OpenBSD should consider time reported by VirtualBox as UTC time. So if this option is not checked, the VirtualBox will report local time to OpenBSD, OpenBSD misunderstands it as UTC time and add additional 8 hour to local time. This can explain what I have seen.

Reference:
Set date during OpenBSD installation.

 

Include “stdio.h” before Readline library header files

I install Readline library and write a simple program to play with it:

#include <readline/readline.h>
#include <readline/history.h>

int main(void)
{
    char *line_read = readline (">>  ");
    if (line_read && *line_read)
    {
        add_history (line_read);
    }
    ......
}

Build it will generate following errors:

In file included from /usr/include/readline/readline.h:35:0,
                 from readline.c:3:
/usr/include/readline/rltypedefs.h:71:28: error: unknown type name 'FILE'
 typedef int rl_getc_func_t PARAMS((FILE *));
                            ^
/usr/include/readline/readline.h:429:20: error: unknown type name 'FILE'
 extern int rl_getc PARAMS((FILE *));
                    ^
In file included from readline.c:3:0:
/usr/include/readline/readline.h:558:8: error: unknown type name 'FILE'
 extern FILE *rl_instream;
        ^~~~
/usr/include/readline/readline.h:559:8: error: unknown type name 'FILE'
 extern FILE *rl_outstream;
        ^~~~
/usr/include/readline/readline.h:588:8: error: unknown type name 'rl_getc_func_t'
 extern rl_getc_func_t *rl_getc_function;
        ^~~~~~~~~~~~~~
/usr/include/readline/readline.h:917:3: error: unknown type name 'FILE'
   FILE *inf;
   ^~~~
/usr/include/readline/readline.h:918:3: error: unknown type name 'FILE'
   FILE *outf;

The solution is including <stdio.h> before Readline library’s header files:

#include <stdio.h>
#include <readline/readline.h>
#include <readline/history.h>
......

Use Ctxt::isCorrect() to check Ctxt valid in using HElib

During using HElib, if the calculation made Ctxt‘s noise too big, it will cause Ctxt can’t be decrypted successfully, and the decrypted result is messy like this:

333317397173303 1016371194582039 217550837977960
737191953777559 1103851234911944 454685807668230
625213263895453 743713807221034 1036409711005678
447878070619549 603715795412661 948856958008786
......

You can leverage Ctxt::isCorrect() method to check whether Ctxt is still valid or not:

std::cout << "Ctxt is valid: " << c.isCorrect() << '\n';

Reference:
Maybe the bug in EncryptedArray’s shift function.

The subtleties of writing DTrace scripts

(1) Assume you write your DTrace script on Windows and run it on Unix. Because Windows uses \r\n as EOL while Unix uses \n, if you execute it directly, following complain will occur:

: No such file or directory

The solution is to apply dos2unix to convert file format before playing it.

(2) The shebang line of script only accepts 1 argument, and -s option must be the last. For example:

#!/usr/sbin/dtrace -sq

Will generate following error:

dtrace: failed to open q: No such file or directory

While “#!/usr/sbin/dtrace -qs” will be OK. To make additional options take effect, please use #pragma directive:

#pragma D option ...

Reference:
Does DTrace script only support “#pragma D option ..”, not “-x option”?.

The “***Exception: Illegal” error of running googletest

Today, a college told me his project testcases (using googletest) run failed with following errors:

1/6 Test #1: AddTest ....................***Exception: Illegal  1.70 sec
......

I am not familiar with his work nor an expert of googletest, but interested about this exception. After some searching, I bumped into the words from this post:

Given that the GROMACS build system enabled AVX2 SIMD on your VM which seems to not support anything above SSE2, it’s not a surprise that the first math instruction crashes the run.

Immediate solution: set -DGMX_SIMD=SSE2 when configuring.

So my buddy seemed meet the similar problem. After discussing with him, he confirmed his server is also a virtual machine and his issue is the same root cause. To satisfy my own curiosity, I download tfhe whose testcases use AVX and FMA while my machine can only support SSE. Run “make test“:

# make test
Running tests...
Test project /root/Project/tfhe/build
    Start 1: unittests-nayuki-portable
1/4 Test #1: unittests-nayuki-portable ........   Passed    8.59 sec
    Start 2: unittests-nayuki-avx
2/4 Test #2: unittests-nayuki-avx .............***Exception: Illegal  2.88 sec
    Start 3: unittests-spqlios-avx
3/4 Test #3: unittests-spqlios-avx ............***Exception: Illegal  2.86 sec
    Start 4: unittests-spqlios-fma
4/4 Test #4: unittests-spqlios-fma ............***Exception: Illegal  2.85 sec

25% tests passed, 3 tests failed out of 4

Total Test time (real) =  17.19 sec

The following tests FAILED:
          2 - unittests-nayuki-avx (ILLEGAL)
          3 - unittests-spqlios-avx (ILLEGAL)
          4 - unittests-spqlios-fma (ILLEGAL)
Errors while running CTest
make: *** [Makefile:95: test] Error 8

We can see “Exception: Illegal” errors are reported again.