Commit 71dacd44 authored by Cedric Roux's avatar Cedric Roux
Browse files

hotfix: clear memory after allocation

parent 25d36e3a
...@@ -62,6 +62,7 @@ void mac_top_init_eNB(void) ...@@ -62,6 +62,7 @@ void mac_top_init_eNB(void)
RC.mac = RC.mac =
(eNB_MAC_INST **) malloc16(RC.nb_macrlc_inst * (eNB_MAC_INST **) malloc16(RC.nb_macrlc_inst *
sizeof(eNB_MAC_INST *)); sizeof(eNB_MAC_INST *));
bzero(RC.mac, RC.nb_macrlc_inst * sizeof(eNB_MAC_INST *));
} }
AssertFatal(RC.mac != NULL, AssertFatal(RC.mac != NULL,
"can't ALLOCATE %zu Bytes for %d eNB_MAC_INST with size %zu \n", "can't ALLOCATE %zu Bytes for %d eNB_MAC_INST with size %zu \n",
  • Cedric, in my opinion this is no fix. If the allocation fails, this will directly lead to a segfault (you are testing for a successful allocation afterwards). Furthermore, in [1] you criticized that the logic was strange because this init function would not always allocate memory, but this function does exactly this(!). In fact, the current version does the same as what I proposed but is more ugly.

    The bug with FlexRAN possibly accessing memory between malloc16() and bzero() is still in there, which is also addressed by [1].

    [1] 52afb00f

  • Agreed, I failed. The Assert should be done before bzero.

    It is a quick and dirty solution to remove the crash some people had before I left for holidays. Was done in a hurry. Not good.

    I don't think memory is always allocated. It is done only the first time the function is called, no? (let's forget about multi-threads for a second)

    For flexran that uses the structure before it is created, I'll let you deal with it.

    Your work will go to develop, that is for sure. This was really a quick and dirty fix before holidays. And it "works", I tested it: before => crash, after => no crash.

  • mentioned in commit e5d8179b

    Toggle commit list
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment