Test failures with ALLOC=STATIC

[sebastinas]

When building with ALLOC=STATIC, some tests fail.

$ ./bin/test_pc
-- Tests for the PC module:

-- Curve B12-P381:

[...]

-- Group G_T:

[...]

** Arithmetic:

Testing if multiplication is commutative...                                   
ERROR: not enough memory.

$ ./bin/test_pp

-- Tests for the PP module

-- Curve B12-P381:

** Arithmetic

Testing if miller addition is correct...                                      [PASS]
Testing if miller addition in affine coordinates is correct...                [PASS]
Testing if miller addition in projective coordinates is correct...            [PASS]
Testing if basic projective miller addition is consistent...                  [PASS]
Testing if lazy-reduced projective miller addition is consistent...           [PASS]
Testing if miller doubling is correct...                                      [PASS]
Testing if miller doubling in affine coordinates is correct...                [PASS]
Testing if miller doubling in projective coordinates is correct...
ERROR: not enough memory.

$ valgrind ./bin/test_cp
[ ...]

Testing if vbnn_ibs is correct...                                             [PASS]
==17621== Invalid free() / delete / delete[] / realloc()
==17621==    at 0x4C2ED5B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17621==    by 0x11DB15: vbnn_ibs (test_cp.c:795)
==17621==    by 0x125F64: main (test_cp.c:1180)
==17621==  Address 0xffefff9c0 is on thread 1's stack
==17621==  in frame #1, created by vbnn_ibs (test_cp.c:737)
==17621==
==17621== Invalid free() / delete / delete[] / realloc()
==17621==    at 0x4C2ED5B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17621==    by 0x11DBCA: vbnn_ibs (test_cp.c:796)
==17621==    by 0x125F64: main (test_cp.c:1180)
==17621==  Address 0xffefff900 is on thread 1's stack
==17621==  in frame #1, created by vbnn_ibs (test_cp.c:737)
==17621==
==17621== Invalid free() / delete / delete[] / realloc()
==17621==    at 0x4C2ED5B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17621==    by 0x11DC7F: vbnn_ibs (test_cp.c:797)
==17621==    by 0x125F64: main (test_cp.c:1180)
==17621==  Address 0xffefff860 is on thread 1's stack
==17621==  in frame #1, created by vbnn_ibs (test_cp.c:737)
==17621==

[dfaranha]

Thanks for the notification! Quick question: are you using ALLOC=STATIC for any reason?
We plan to soon eliminate this in favor of stack-based allocation only.

[sebastinas]

No, I was just checking if the different allocation methods make a difference performance-wise.

[alinush]

Hi Diego,

When you say stack-based allocation only, do you mean ALLOC=STACK or ALLOC=AUTO?

ALLOC=STACK seems to fail the RELIC tests with segfaults:
After building with:

cmake -DALLOC=STACK -DWORD=64 -DRAND=UDEV -DSHLIB=ON -DSTLIB=ON -DSTBIN=OFF -DTIMER=HREAL -DCHECK=on -DVERBS=on -DARITH=x64-asm-254 -DFP_PRIME=254 -DFP_METHD="INTEG;INTEG;INTEG;MONTY;LOWER;SLIDE" -DCOMP="-O3 -funroll-loops -fomit-frame-pointer -finline-small-functions -march=native -mtune=native" -DFP_PMERS=off -DFP_QNRES=on -DFPX_METHD="INTEG;INTEG;LAZYR" -DPP_METHD="LAZYR;OATEP" ..

...many tests fail:

alinush@dvorak [~/repos/relic/build] (master %) $ ctest
Test project /home/alinush/repos/relic/build
      Start  1: test_err
 1/34 Test  #1: test_err .........................   Passed    0.01 sec
      Start  2: test_bn
 2/34 Test  #2: test_bn ..........................***Exception: SegFault  2.59 sec
      Start  3: test_dv
 3/34 Test  #3: test_dv ..........................   Passed    0.02 sec
      Start  4: test_fp
 4/34 Test  #4: test_fp ..........................***Exception: SegFault  0.11 sec
      Start  5: test_fpx
 5/34 Test  #5: test_fpx .........................***Exception: SegFault  0.12 sec
      Start  6: test_fb
 6/34 Test  #6: test_fb ..........................   Passed    1.29 sec
      Start  7: test_fbx
 7/34 Test  #7: test_fbx .........................   Passed    0.14 sec
      Start  8: test_ep
 8/34 Test  #8: test_ep ..........................***Exception: SegFault  0.11 sec
      Start  9: test_epx
 9/34 Test  #9: test_epx .........................***Exception: SegFault  0.12 sec
      Start 10: test_eb
10/34 Test #10: test_eb ..........................   Passed   39.60 sec
      Start 11: test_ed
11/34 Test #11: test_ed ..........................   Passed    0.00 sec
      Start 12: test_ec
12/34 Test #12: test_ec ..........................***Exception: SegFault  0.11 sec
      Start 13: test_pc
13/34 Test #13: test_pc ..........................***Exception: SegFault  0.11 sec
      Start 14: test_pp
14/34 Test #14: test_pp ..........................***Exception: SegFault  0.12 sec
      Start 15: test_md
15/34 Test #15: test_md ..........................   Passed   22.61 sec
      Start 16: test_cp
16/34 Test #16: test_cp ..........................***Exception: SegFault  1.82 sec
      Start 17: test_rand
17/34 Test #17: test_rand ........................   Passed    0.00 sec
      Start 18: test_core
18/34 Test #18: test_core ........................   Passed    0.00 sec
      Start 19: bench_err
19/34 Test #19: bench_err ........................   Passed    0.00 sec
      Start 20: bench_bn

[dfaranha]

Thanks for the report! I am afraid that the ASM backend is not compatible with the STACK allocator. I am currently in the process of eliminating all the allocators and leaving only AUTO.

[alinush]

I see! Good to know! Edited my post, I meant to say ALLOC=STACK segfaults!

[FiloSottile]

I am currently in the process of eliminating all the allocators and leaving only AUTO.

Please please don't.

Array type typedefs are extremely obscure to a non-C developer, and cgo just plainly doesn't support them without hacks.

[conradoplg]

cgo just sees the function declarations, right? Can't we just fix them? (e.g. use fp_st* instead of fp_t in function declarations).

I've also grown to dislike the typedefs...

[dfaranha]

@FiloSottile Thanks for the feedback! Does this mean you have to use ALLOC=DYNAMIC to use cgo?

[FiloSottile]

Correct, fp_st* function declarations would work, which is effectively what I obtain by setting ALLOC=DYNAMIC, which works. cgo balks at trying to understand how to map a C array typedef in the arguments to Go-world.

Also, having explicit control over where the memory is, whether in the Go heap (by instantiating a C.ep_st in Go and then taking a pointer) or in the C heap (by calling ep_new) is very useful.

(And also, I was personally very confused about where this memory is for a bit.)

[dfaranha]

As a step towards a simpler memory allocation and error-handling model, I'm killing ALLOC = STACK soon. :)

[dfaranha]

ALLOC=STACK was killed a long time ago, but ALLOC=DYNAMIC is still preserved for wrappers and other needs. Closing this and leaving #60 alive for further thought.