I am running my program though valgrind, but it appears it is generating errors caused by the tool itself? All my errors look like the following, but from reading through other posts, it seems that usually the at line tells you where in your program the offending malloc occurs, but all my at lines are coming from valgrind. Are these legit errors in my program?
==10551== 32,808 (24 direct, 32,784 indirect) bytes in 1 blocks are definitely lost in loss record 840 of 843
==10551== at 0x54D7: malloc_zone_malloc (in /usr/local/Cellar/valgrind/3.8.1/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==10551== by 0x7C5171: NXCreateMapTableFromZone (in /usr/lib/libobjc.A.dylib)
==10551== by 0x7C4722: _read_images (in /usr/lib/libobjc.A.dylib)
==10551== by 0x7C39EB: map_images_nolock (in /usr/lib/libobjc.A.dylib)
==10551== by 0x7C34F3: map_images (in /usr/lib/libobjc.A.dylib)
==10551== by 0x7FFF5FC04936: dyld::notifyBatchPartial(dyld_image_states, bool, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==10551== by 0x7FFF5FC0467C: dyld::registerImageStateBatchChangeHandler(dyld_image_states, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==10551== by 0xA99ED9: dyld_register_image_state_change_handler (in /usr/lib/system/libdyld.dylib)
==10551== by 0x7C204C: _objc_init (in /usr/lib/libobjc.A.dylib)
==10551== by 0x6BB27: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==10551== by 0x7FFF5FC13377: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==10551== by 0x7FFF5FC13761: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==10551==
I used homebrew to install valgrind. It probably has something to do with this error:
==10551== WARNING: Support on MacOS 10.8 is experimental and mostly broken.
==10551== WARNING: Expect incorrect results, assertions and crashes.
but I just want to make sure (by someone who has used this before) that these errors are not coming from my program. (I am on 10.8).
Valgrind replaces the default implementations of the library functions allocating and deallocating memory (malloc(), calloc(), realloc(), free() being the most important), by its own to track calls to them and do the bookkeeping. The backtrace shows the call stack to the malloc() call that allocated the memory that was never free()'d. So the problem doesn't lie in malloc() itself - but rather in the code calling malloc() without corresponding free().
The error-checking tools detect numerous problems in the system libraries, such as the C library, which come pre-installed with your OS. You can't easily fix these, but you don't want to see these errors (and yes, there are many!) So Valgrind reads a list of errors to suppress at startup. A default suppression file is created by the ./configure script when the system is built.
You can modify and add to the suppressions file at your leisure, or, better, write your own. Multiple suppression files are allowed. This is useful if part of your project contains errors you can't or don't want to fix, yet you don't want to continuously be reminded of them.
Note: By far the easiest way to add suppressions is to use the --gen-suppressions=yes option described in Core Command-line Options. This generates suppressions automatically. For best results, though, you may want to edit the output of --gen-suppressions=yes by hand, in which case it would be advisable to read through this section.
Each error to be suppressed is described very specifically, to minimise the possibility that a suppression-directive inadvertently suppresses a bunch of similar errors which you did want to see. The suppression mechanism is designed to allow precise yet flexible specification of errors to suppress.
Related
Is there anyway I can load a shared library into shared memory in a process so that some other process can simply map that shared memory (to the same address) and simply invoke functions? I understand that the external in the shared library need to have an additional jump into process-specific memory locations to call into appropriate functions (like elf plt). But, is such a thing viable with today's tools.
But, is such a thing viable with today's tools.
Not with today's tools, nor ever.
Sure, if your shared library has completely self-contained functions, then it will work. But the moment your library references external data or functions, you will crash and burn.
I understand that the external in the shared library need to have an additional jump into process-specific memory locations to call into appropriate functions
I don't think you understand. Let's consider an example:
void *foo() { return malloc(1); }
When this is built into a shared library on Linux, the result is:
0x00000000000006d0 <+0>: mov $0x1,%edi
0x00000000000006d5 <+5>: jmpq 0x5c0 <malloc#plt>
and
Dump of assembler code for function malloc#plt:
0x00000000000005c0 <+0>: jmpq *0x200a5a(%rip) # 0x201020 <malloc#got.plt>
0x00000000000005c6 <+6>: pushq $0x1
0x00000000000005cb <+11>: jmpq 0x5a0
So the question is: where will jmpq *0x200a5a(%rip) go in the second process. Answer: one of two places.
If the first process has already called malloc (very likely), then the jmpq will go to address of malloc in the first process, which is exceedingly unlikely to be the address of malloc in the second process, and more likely to be unmapped, or be in the middle of some data. Either way, you crash.
If the first process has not yet called malloc, then the jmpq in the second process will jump to address of the runtime loader (ld-linux.so.2 or similar on Linux, ld.so on Solaris) resolver function. Again, that address is very unlikely to also be the address of the resolver in the second process, and if it's not, you crash.
But it gets worse from here. If by some improbable magic you ended up actually calling malloc in the second process, that malloc is itself very likely to crash, because it will try to use data structures it has set up previously, using memory obtained from sbrk or mmap. These data structures are present in the first process, but not in the second, and so you crash again.
I remember I read the somewhere before,but I can't find the offical document now.
are all instructions in jvm all atomic?
like:
iinc
iload
aload
all atomic?
The bytecode instructions you mentioned (iinc, iload, aload etc.) operate on the values from the operand stack and on the local variables. These areas are thread-local (see JVMS 2.5, 2.6), that is, speaking about atomicity here is meaningless. I.e. they are NOT implemented using atomic CPU instructions like lock xadd, but nobody should care.
The bytecode instructions that read or write fields and array elements (getfield, putfiled, iastore etc.) are atomic except for long and double types (see JLS 17.7). 32-bit JVM may implement (actually, HotSpot JVM does implement) reading and writing of 64-bit fields with two 32-bit loads or stores, unless the field is declared volatile.
I'm trying to debug my program using Valgrind. I compiled with -g3 -O0 -ggdb. How ever I am unable to see the source code corresponding to the point where Valgrind finds problem. The output just shows the name of the (binary)library.
These addresses are of no interest. They belong to the runtime support code that runs after main and calls destructors of global objects and atexit routines. They do not have any source (that you wrote) associated with them.
You can tell that from their placement between exit and __cxa_finalize in the call stack. No user code could possibly belong there.
Silly question, but do you have the source for that library? If not, and that library wasn't compiled with debugging symbols, valgrind isn't going to decompile the binary and show you source.
Valgrind is complaining about a double free on exit. The line:
Address 0x5980ec0 is 0 bytes inside a block of size 29 free'd
Is pointing you where this memory block was previously freed. Taking into account that this is also in exit I can think of two possible reasons:
Some global and static variables that are been freed (with C++ I've seen this problem when directly assigning two global objects, containing pointers, using default copy constructor. As both pointers refer to same memory address, on exit, this is freed twice).
libslm.so has been loaded by using dlopen, then, on exit, it is closed and can also cause some problems with currently managed memory.
I'm assuming that libslm.so is yours so, I think, in both scenarios is important to know something about lines you marked. Have you checked that the path in the log is the same were you have your libraries with debug information? Is AddrScram linked against these libraries (with same exact path)?
I've recently discovered the following in my code:
for (NSInteger i; i<x; i++){
...
}
Now, clearly, i should have been initialised. What I find strange is that while in "debug" profile (XCode), this error goes undetected and the for loop executes without issue. When the application is released using the "release" profile, a crash occurs.
What flags are responsible for letting this kind of mistake execute in "debug" profile?
Thanks in advance.
This could be considered a Heisenbug. A declaration without an initialization will typically allocate some space in the stack frame for the variable and if you read the variable you will get whatever happened to be at that location in memory. When compiled for the debug profile the storage for variables can shift around compared to release. It just happens that whatever is in that location in memory for debug mode does not cause a crash (probably a positive number) but when in release mode it is some value that causes a crash (probably a negative number).
The clang static analyser should detect this. I have the analyse when building option switched on always.
In the C language, using an initialized variable isn't an error but an Undefined Behavior.
Undefined behavior exists because C is designed to be a very efficient low-level language. Using an initialized variable is undefined behavior because it allows the compiler to optimize the variable allocation, as no default value is required.
But the compiler is licensed to do whatever he wants when an undefined behavior occurs. The C Standard FAQ says:
Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended.
So any implementation of an undefined behavior is valid (even if it produces code that formats your hard drive).
Xcode uses different optizations for Debug and Release configurations. Debug configuration has no optimization (-O0 flag) so the compiled executable must stays close to your code, allowing you to debug it more easily. On the other hand, Release configuration produces strongly optimized executables (-Os flag) because you want your application to run fast.
Due to that difference, undefined behaviours may (or may not) produce different results in Release and Debug configurations.
Though the LLVM compiler is quite verbose, it does not emit warnings by default for undefined behaviors. You may however run the static analyzer, which can detect that kind of issues.
More information about undefined behaviors and how they are handled by compilers in What Every Programmer Should Know About Undefined Behavior.
I doubt it is so much flags as the compiler is optimizing out the "unused" variable i. Release mode includes far more optimizations then debug mode.
Different compiler optimizations may or may not use a different memory location or register for you uninitialized variable. Different garbage (perhaps from previously used variables, computations or addresses used by your app) will be left in these different locations before you start using the variable.
The "responsibility" goes to not initializing the variable, as what garbage is left in what locations may not be visible to the compiler, especially in debug mode with most optimatizations off (e.g. you got "lucky" with the debug build).
i has not been initialized . You are just declaring the i variable not initializing the variable.
Writing just NSInteger i; just declares a variable not initializes it.
You can initialize the variable by below mentioned code.
for (NSInteger i=1; i<x; i++){
...
}
I'd like to instrument syscall brk (and other calls but this in first order, it's most important to me) in given binary (preferably on actual syscall/sysenter level (x86-64 and x86) of making sys_brk call).
Main goal:
A part of sandbox which gives fixed amount of memory to jailed process
So, I'd like to get rid of brk system calls (and most preferably others in next order) and simulate memory allocations under fixed limit. Fixed limit is memory space, available to program. (You can think about it like making a kind of sandbox with fixed amount of available memory)
How to implement (one of) some example possible solutions (or yours solution):
just changing instructions to NOP
As brk returns 0 on success, simulate it's successes with setting operations that sets memory (register) state , as brk would be called with success.
More complex... instrument with code (or function call) which simulates success memory allocations under fixed limit.
Most flexible (maybe overkill in my case) to change this syscall into function call and add provided function to binary.
Given binary is code that can be malicious in one of two (most preferably both :) ) forms:
shared library - here I can setup environment before function call (for example do brk call in controlled way)
program binary - in this case we need to give program fixed amount of memory (by caller, or on begining of program "one syscall"), cause it can not allocate. Example of calling such program should be included in answer.
As problem is highly connected with many other aspects, I tried do my best in separating it as question, but please give me advice if I should specify something more or less.
Answers with implementation, links to resources (books, tutorials) are welcome.
(I am most interested in Linux, and solution that is reliable, so that people preparing binaries, even in assembler, would not have to worry about execution of their code)
LD_PRELOAD will trap C calls to brk(), but it won't trap the actual system call (int/syscall instruction). There's no portable way to trap those, but on Linux, ptrace will do it. Memory can also be allocated to a program by mmap(), so you'll need to intercept that call too.
Of course, what it seems you're really looking for is rlimit().
Yeah, I don't think you want valgrind for this.
You can use LD_PRELOAD or linker tricks to capture brk(2): see these other discussions:
Function interposition in Linux without dlsym
Overriding 'malloc' using the LD_PRELOAD mechanism
Code might look like this:
#include <unistd.h>
#include <dlfcn.h>
/* prototype int brk(void *addr); */
static int (*real_brk)(void *addr) = NULL;
int brk(void * addr) {
real_brk = dlsym(RTLD_NEXT, "brk");
if (real_brk == NULL) {
fprintf(stderr, "error mapping brk: %s\n", dlerror());
return -1;
}
printf("calling brk(2) for %p\n", addr);
return (real_brk (addr));
}`
and then LD_PRELOAD that to intercept brk(2)