Git Product home page Git Product logo

Comments (2)

zacky1972 avatar zacky1972 commented on May 28, 2024

If run the following on iex, such a segmentation fault doesn't occur:

iex> LogisticMap.logistic_map_10_pelemay(1..16)

from pelemay.

christianjgreen avatar christianjgreen commented on May 28, 2024

Hey there! I was looking into this a bit and believe there is not enough space being allocated for the internal vector holding the list.

Valgrind revealed the following:

==30428== 1 errors in context 1 of 35:
==30428== Thread 6 2_scheduler:
==30428== Invalid read of size 8
==30428==    at 0x4B3245F0: map_elem1_plus_1_mult_1_mult_elem1_mod_6700413_kernel_i64 (map_elem1_plus_1_mult_1_mult_elem1_mod_6700413_kernel.c:25)
==30428==    by 0x4B323DAF: map_elem1_plus_1_mult_1_mult_elem1_mod_6700413_yielding_nif (libnifelixirlogisticmap.c:597)
==30428==    by 0x3909A0: execute_nif (erl_nif.c:3117)
==30428==    by 0x188CA8: process_main (beam_cold.h:184)
==30428==    by 0x1A53EE: sched_thread_func (erl_process.c:8486)
==30428==    by 0x4B532C: thr_wrapper (ethread.c:122)
==30428==    by 0x49E6608: start_thread (pthread_create.c:477)
==30428==    by 0x4B22292: clone (clone.S:95)
==30428==  Address 0x49044118 is 8 bytes after a block of size 64 alloc'd
==30428==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==30428==    by 0x3C887D: erts_sys_alloc (sys.c:871)
==30428==    by 0x388BB4: erts_alloc_fnf (erl_alloc.h:294)
==30428==    by 0x38AD65: enif_alloc (erl_nif.c:529)
==30428==    by 0x4B325649: enif_get_int64_vec_from_list (basic.c:80)
==30428==    by 0x4B32396E: map_elem1_plus_1_mult_1_mult_elem1_mod_6700413_nif (libnifelixirlogisticmap.c:536)
==30428==    by 0x188CA8: process_main (beam_cold.h:184)
==30428==    by 0x1A53EE: sched_thread_func (erl_process.c:8486)
==30428==    by 0x4B532C: thr_wrapper (ethread.c:122)
==30428==    by 0x49E6608: start_thread (pthread_create.c:477)
==30428==    by 0x4B22292: clone (clone.S:95)

In basic.c:80 the line is

size_t nn = CACHE_LINE_SIZE;
ErlNifSInt64 *t = (ErlNifSInt64 *)enif_alloc(nn);

Since t is being used as an array below (&t[i++]) is the sizeof() function missing during the allocation?

I was playing around with something like this that seemed to clear the mem leaks.
Where length is derived from enif_get_list_lengh since *vec_l might be NULL.

size_t nn = CACHE_LINE_SIZE;
ErlNifSInt64 *t = (ErlNifSInt64 *)enif_alloc(sizeof(ErlNifSInt64) * length);

I'd like to get your thoughts before moving forward with a PR :)

from pelemay.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.