Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[linux] instrument auxiliary alloc routines: memalign(), valloc(), etc. #94

Open
derekbruening opened this issue Nov 28, 2014 · 3 comments
Open

[linux] instrument auxiliary alloc routines: memalign(), valloc(), etc. #94

derekbruening opened this issue Nov 28, 2014 · 3 comments
Assignees
@derekbruening
Labels
Migrated OpSys-Linux Priority-Medium

Comments

@derekbruening
Copy link
Contributor

From derek.br...@gmail.com on December 10, 2010 17:57:33

PR 406323

some *nix allocators provide additional routines beyond malloc, calloc, realloc.
some of these are obsolete.
some merely provide information, but we may need to intercept them in order to
hide our redzones.

  • memalign and valloc
  • posix_memalign
  • mallinfo
  • mallopt
  • independent_calloc
  • independent_comalloc
  • pvalloc
  • cfree
  • malloc_trim
  • malloc_usable_size => I already handle (and use) this one
  • malloc_stats

I've recently seen:

Error #1: UNADDRESSABLE ACCESS: reading 0x02a9c6d4-0x02a9c6d8 4 byte(s)
Elapsed time = 0:00:00.187 in thread 337403
Note: prev lower malloc: 0x02a9bed0-0x02a9c6c8
0x10e236c6 libc.so.6 !mallopt
??:0
0x10e2450e libc.so.6 !mallopt
??:0
0x10e2559e libc.so.6 !memalign
??:0
0x10e25775 libc.so.6 !posix_memalign
??:0
0x10e25718 libc.so.6 !posix_memalign
??:0
0x10ba664f libglib-2.0.so.0 !g_slice_free1
??:0
0x10ba6908 libglib-2.0.so.0 !g_slice_alloc
??:0
0x10b70670 libglib-2.0.so.0 !g_array_sized_new
??:0
0x10b70725 libglib-2.0.so.0 !g_array_new
??:0
0x10baf4de libglib-2.0.so.0 !g_static_private_set
??:0
0x10b7e17c libglib-2.0.so.0 !g_get_filename_charsets
??:0
0x10b7e32d libglib-2.0.so.0 !g_get_filename_charsets
??:0
0x10baf867 libglib-2.0.so.0 !g_thread_init_glib
??:0
0x10b48dd4 libgthread-2.0.so.0 !g_thread_init
??:0

xref PR 573482: glib custom allocator leads to reported leaks
add "G_SLICE=always-malloc G_DEBUG=gc-friendly" when running?
or would it still use posix_memalign()?
should just implement interception of posix_memalign()

PR 406323, part 1: instrument auxiliary alloc routines: mallopt(), etc.

  • add handling for the simpler aux routines, the ones that just ask
    for stats or tweak behavior or are identical to existing routines:
    cfree, mallopt, mallinfo, malloc_stats, malloc_trim, malloc_get_state
  • add warnings on unhandled alloc routines
  • add tests/memalign.c that calls these routines

Original issue: http://code.google.com/p/drmemory/issues/detail?id=94
@zhaoqin zhaoqin mentioned this issue Aug 19, 2015
Open
@derekbruening derekbruening self-assigned this Aug 19, 2015
@derekbruening
Copy link
Contributor Author

Assigning to me because I have a tree where I started implementing replacement memalign & co.: adding alignment support to the allocator

@derekbruening
Copy link
Contributor Author

For aligned mallocs, I went w/ a solution that puts the pre-malloc padding
on the free list (b/c of several complications of keeping it as padding,
incl how to tell clients like drmem and drheap who want to mark redzone
shadow or fill w/ pattern or add to usage stats: would complicate
interface; along w/ complex header arrangement problems). That's a great
solution for the allocator itself. But then we report an underflow as a
use-after-free:

    p = NULL;
    res = posix_memalign(&p, 256, 42);
    c = *((char *)p - 1); /* unaddr */

~~Dr.M~~ Error #1: UNADDRESSABLE ACCESS of freed memory: reading 0x0804f2ff-0x0804f300 1 byte(s)
~~Dr.M~~ # 0 main               [/work/drmemory/git/src/tests/memalign.c:70]
~~Dr.M~~ Note: @0:00:00.902 in thread 26541
~~Dr.M~~ Note: refers to 1 byte(s) before next malloc
~~Dr.M~~ Note: next higher malloc: 0x0804f300-0x0804f32a
~~Dr.M~~ Note: prev lower malloc:  0x0804f150-0x0804f1d8
~~Dr.M~~ Note: 0x0804f2ff-0x0804f300 overlaps memory 0x0804f240-0x0804f698 that was freed
~~Dr.M~~ Note: instruction: movzx  0xffffffff(%eax) -> %eax

A suggestion is to not report if there's no free callstack. I guess we have -delay_frees_stack on by default (w/ small # frames: that was the perf compromise) so I will try that.

@derekbruening
Copy link
Contributor Author

I am not adding support for memalign for wrapping

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@derekbruening derekbruening

Labels
Migrated OpSys-Linux Priority-Medium
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@derekbruening