I use fdopen to associate a stream with an open file.
When I close() the file, is the stream automatically disassociated as well, and all stream memory returned to the OS, or do I need to be aware of the fdopen'd file and close it in a specific manner?
-Adam
close() is a system call. It will close the file descriptor in the kernel, but will not free the FILE pointer and resources in libc. You should use fclose() on the FILE pointer instead, which will also take care of closing the file descriptor.
Related
I'm learning DirectX 2D.
When i close my application, i have noticed there is a problem in IWICImagingFactory* type variable.
I use only one IWICImagingFactory* variable in whole program. So i initiate it once when i start program and destroy(release) once when i close my program.
But if i release IWICImagingFactory* variable after call CoUninitialize() function, there is error.
Factorys::~Factorys()
{
SAFE_RELEASE(mpD2DFactory);
SAFE_RELEASE(mpWICFactory);
}
↓ Is is korean, meaning : error throw, access violation, "this->mpWICFactory->" is 0x6EEFC7D8
enter image description here
I noticed "this->mpWICFactory->" has problem when i try to release WICFactory after call CoUninitialize(). So i read about CoUninitialize() in here : "https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize"
And i read this part in the link : Closes the COM library on the current thread, unloads all DLLs loaded by the thread.
Quetion 1 : When i call CoUninitialize() function, WICfactory is released automatically?
Quetion 2 : Do i have to release WICFactory before call CoUninitialize() function?
Yes, as you mention in the question, CoUninitialize will unload all dependent loaded libraries (WICFactory being one of them).
So trying to unload an already unloaded library will get you an AV or another Error.
It's not "really necessary" to release WICFactory, since CoUninitialize will also do it (and since you release when program closes anyway, even if you don't call CoUninitialize the Operating System will do it for you).
However, I strongly recommend that you still release your resources (so yes, release WICFactory, then call CoUninitialize ), having code that knows how to do correct cleanup will always be better in the long term (no matter if you use smart pointers or not, that is up to you).
How can I be aware of register spilling by looking at an objdump file?
My thought is that it can be done by tracking the stack pointer: moving sp beyond function prologue and epilogue, indicates register spilling.
I want to know which lines of codes are doing register spilling. Also, where are the registers restored pointed to global variable, also stack?
Register spilling doesn't require moving the stack pointer, a local variable may be spilled to the stack and constantly used directly from there while still in the current frame, and the compiler would just use the stack frame with its offset instead of a register.
Your best bet is just looking for memory addresses being read and/or written to constantly. This may even happen where there are available registers around because of compiler deficiencies, or inability to prove that no other thread/code unit are accessing some local variable by addr (for example if the variable address is copied somewhere out of scope). In such cases maintaining that variable in memory is necessary.
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.
My application needs to write a short packet of data periodically to a group of TCP connections, each of which is encapsulated by an NSFileHandle. NSFileHandle offers asynchronous reading, but for writing, I think I have to use writeData (my Objective-C implementation, GNUStep, does not have the writeabilityHandler property, unfortunately).
My question is: will writeData throw an exception if the TCP file descriptor is not ready for writing, or will it block indefinitely? I've been trying to test this, but it's hard to get the other side of the connection in the proper state. The ideal thing for me would be if writeData would throw an exception, so I could try writing again later.
I would like to save an objective-c block to a file (or any other storage e.g. FTP server) and later load it from there and execute it.
From the Blocks Programming Guide > Using Blocks > Copying Blocks, I know that blocks can be stored in the heap. Because anything stored there can be modified, I think that it is possible to read and write arbitrary content from/to the heap and treat the data as a block.
My problem is, how do you save a block to a file? I don't even know what its structure is/how many bytes it covers. I highly doubt that doing a sizeof() and then reading/writing as many bytes is sufficient. Please help me in finding a start to read and write blocks to/from memory and to understand how they are composed.
Let's start from this code:
void (^myBlock)(void) = ^{ printf("Hello, I'm a Block\n"); };
printf("block size: %lu\n", sizeof(myBlock));
myBlock();
Output:
block size: 4
Hello, I'm a Block
As you can imagine, if this works, a long list of fascinating concepts could be implemented in iOS. Just to name a few:
Downloading executable code (as a block) from the web on the fly, storing it in the heap, and executing it, thus making dynamically linked libraries possible in iOS. From this idea, many more possibilities spawn which are simply too many to write in here.
Compiling code in-app and execute immediately, thus enabling any kind of natively executed scripting languages in iOS apps.
Manipulating code at runtime on the machine level in iOS. This is an important topic for AI and evolutionary/random algorithms.
A block object can be stored in the heap. But a block object itself, like other objects, does not contain executable code -- it only contains captured variables, some metadata, and a pointer to the underlying function that is executed. Even if you could hypothetically serialize block objects, you could only unserialize them on a system that has implemented the same block, i.e. has the same executable code.
To make an analogy, what you are saying applies equally with a normal Objective-C object -- Objective-C objects exist on the heap, you can serialize many Objective-C objects, and Objective-C objects contain executable "methods" that you can call on them. Does that mean you can "download executable code (as an object) from the web on the fly, storing it in the heap, and call methods on it, thus making dynamically linked libraries possible in iOS."? Of course not. You can only potentially unserialize objects on a system that has the same class.
It is not possible:
when you copy the block on the heap you are copying the address of the block itself, not the code of the block.
Moreover the possibility of run not compiled and signed code is against the concept of sandbox, and it'd open the possibility to run evil code in your app breaking the security.
You could implement a custom language interpreter in your app to run a interpred code, but it would be against the Apple policy and it would be rejected during the review process.