DynamoRIO / DynamoRIO/dynamorio
dr_raw_tls_calloc does not init slots to 0
- Dominant language
- C
- Stars
- 3.2k
- Forks
- 629
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 31
Description
**Describe the bug**
I started implementing a new tool in DynamoRIO today, and assumed that dr_raw_tls_calloc will init slots to 0 in accordance to the docs pasted here:
> These slots will be initialized to 0 for each new thread.
However, this does not seem to be the case. Is this a bug in DR or a mistake in the docs (or maybe a possible bug in my test case)
**To Reproduce**
Test case:
```
#include "drmgr.h"
#include "drreg.h"
#include "drutil.h"
#include "utils.h"
reg_id_t tls_raw_reg;
uint tls_raw_base;
static void event_exit(void);
static void **get_tls_addr(int slot_idx) {
byte *seg_base = dr_get_dr_segment_base(tls_raw_reg);
byte *addr = (byte *) ( seg_base + tls_raw_base + slot_idx * sizeof(void *));
return *((void **) addr);
}
static void
event_thread_init(void *drcontext)
{
DR_ASSERT(get_tls_addr(0) == NULL);
DR_ASSERT(get_tls_addr(1) == NULL);
DR_ASSERT(get_tls_addr(2) == NULL);
DR_ASSERT(get_tls_addr(3) == NULL);
}
DR_EXPORT void dr_client_main(client_id_t id, int argc, const char *argv[]) {
drmgr_init();
drutil_init();
dr_register_exit_event(event_exit);
dr_raw_tls_calloc(&(tls_raw_reg), &(tls_raw_base), 4, 0);
if (!drmgr_register_thread_init_event(event_thread_init))
DR_ASSERT(false);
}
static void event_exit() {
if (!drmgr_unregister_thread_init_event(event_thread_init))
DR_ASSERT(false);
dr_raw_tls_cfree(tls_raw_base, 4);
drutil_exit();
drmgr_exit();
}
```
**Expected behavior**
Slots should be zero at thread init events.
**Screenshots or Pasted Text**
```
ASSERT FAILURE: /home/john/main_dr/dynamorio/api/samples/testcase.c:25: get_tls_addr(1) == ((void *)0) ()
```
**Versions**
Current head commit, on 32-bit Linux
**Additional context**
I looked at how current DR tools make use of dr_raw_tls_calloc. Dr Memory and drreg both write to the slots before use.
Assign this issue to me. I would imagine we are missing a memset somewhere/or the doc is incorrect due to some hard limitation which I am not aware of. Any pointer where I should look in DR to fix this would also help me.
Contributor guide
Assessment
This issue has not been assessed yet.