I wrote the basic Hello world code in C++.
I then built and ran it using CodeBlocks.
#include <iostream>
using namespace std;
int main()
{
cout<<"Hello World!";
}
I then did "Build and run" successively many times (doing nothing else on the system meanwhile) and each time the execution time was different. Why is this?
Related
I have a very simple program as follows that just creates an isolate, then sleeps:
#include <libplatform/libplatform.h>
#include <v8-platform.h>
#include <v8.h>
#include <stdio.h>
#include <unistd.h>
using v8::Isolate;
int main() {
std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();
v8::V8::InitializePlatform(platform.get());
v8::V8::Initialize();
v8::Isolate::CreateParams create_params;
create_params.array_buffer_allocator = v8::ArrayBuffer::Allocator::NewDefaultAllocator();
Isolate* isolate = v8::Isolate::New(create_params);
printf("Sleeping...\n");
usleep(1000 * 1000 * 100);
printf("Done\n");
return 0;
}
When i run this program, i can then check the number of threads the process has created with ps -T -p <process_id>, and i see that on my 8 core machine, v8 creates 7 extra threads all named "V8 WorkerThread", and on my 16 core machine i get 8 instances of this "V8 WorkerThread" created.
I am looking to understand what determines the number of extra threads v8 spawns and what the purpose of these threads are. Thanks in advance!
The number of worker threads, when not specified by the embedder (that's you!), is chosen based on the number of CPU cores. In the current implementation, the formula is: number_of_worker_threads = (number_of_CPU_cores - 1) up to a maximum of 8, though this may change without notice. You can also specify your own worker thread pool size as an argument to NewDefaultPlatform.
The worker threads are used for various tasks that can be run in the background, mostly for garbage collection and optimized compilation.
This is my code that works only on Xcode (version 4.5):
#include <stdio.h>
#include <mach/mach_init.h>
#include <mach/mach_vm.h>
#include <sys/types.h>
#include <mach/mach.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <Security/Authorization.h>
int main(int argc, const char * argv[]) {
char test[14] = "Hello World! "; //0x7fff5fbff82a
char value[14] = "Hello Hacker!";
char test1[14];
pointer_t buf;
uint32_t sz;
task_t task;
task_for_pid(current_task(), getpid(), &task);
if (vm_write(current_task(), 0x7fff5fbff82a, (pointer_t)value, 14) == KERN_SUCCESS) {
printf("%s\n", test);
//getchar();
}
if (vm_read(task, 0x7fff5fbff82a, sizeof(char) * 14, &buf, &sz) == KERN_SUCCESS) {
memcpy(test1, (const void *)buf, sz);
printf("%s", test1);
}
return 0;
}
I was trying also ptrace and other things, this is why I include other libraries too.
The first problem is that this works only on Xcode, I can find with the debugger the position (memory address) of a variable (in this case of test), so I change the string with the one on value and then I copy the new value on test on test1.
I actually don't understand how vm_write works (not completely) and the same for task_for_pid(), the 2° problem is that I need to read and write on another process, this is only a test for see if the functions works on the same process, and it works (only on Xcode).
How I can do that on other processes? I need to read a position (how I can find the address of "something"?), this is the first goal.
For your problems, there are solutions:
The first problem: OS X has address space layout randomization. If you want to make your memory images fixed and predictable, you have to compile your code with NOPIE setting. This setting (PIE = Position Independent Executable), is responsible for allowing ASLR, which "slides" the memory by some random value, which changes on every instance.
I actually don't understand how vm_write works (not completely) and the same for task_for_pid():
The Mach APIs operate on the lower level abstractions of "task" and "Thread" which correspond roughly to that of the BSD "process" and "(u)thread" (there are some exceptions, e.g. kernel_task, which does not have a PID, but let's ignore that for now). task_for_pid obtains the task port (think of it as a "handle"), and if you get the port - you are free to do whatever you wish. Basically, the vm_* functions operate on any task port - you can use it on your own process (mach_task_self(), that is), or a port obtained from task_for_pid.
Task for PID actually doesn't necessarily require root (i.e. "sudo"). It requires getting past taskgated on OSX, which traditionally verified membership in procmod or procview groups. You can configure taskgated ( /System/Library/LaunchDaemons/com.apple.taskgated.plist) for debugging purposes. Ultimately, btw, getting the task port will require an entitlement (the same as it now does on iOS). That said, the easiest way, rather than mucking around with system authorizations, etc, is to simply become root.
Did you try to run your app with "sudo"?
You can't read/write other app's memory without sudo.
Hey so i've made a text game using the pdCurses library and microsoft opperating system tools. Here are my includes and look below for other explination:
#include <iostream>
#include <time.h> // or "ctime"
#include <stdio.h> // for
#include <cstdlib>
#include <Windows.h>
#include <conio.h>
#include<curses.h>
#include <algorithm>
#include <string>
#include <vector>
#include <sstream>
#include <ctime>
#include <myStopwatch.h> // for keeping times
#include <myMath.h> // numb_digits() and digit_val();
myStopwath/Math.h includes:
#include <stdio.h>
#include <math.h>
#include <tchar.h>
So i've tested the game (which includes a folder containing the .exe and pdcurses.dll) on my computer running windows 7 and it works great, however when running it on another computer which has vista or older my game comes up, but immediatly ends due to the loss of all the players lives almost instantaniously.... how could this be?
If you would like to see the full source code, go to this Link
Thanks!
In the main game loop, you are not initializing the coll variable before passing it to theScreen.check_collision(). If the player is in no danger, then that function does not update this value. Back in the main loop you don't check the return value from check_collision(), and the program is now making decisions based on whatever uninitialized value was in that variable. Welcome to the wide world of Undefined Behavior.
It is likely the difference you're seeing on different OS's is due to the way the different heap managers initialize memory pages. Even if your player survives for a while, after the first collision, that memory location now holds 'X', which is then never cleared, and while the result is still "undefined", on most architectures, this will result in registering a new collision on each iteration, explaining why your "lives" are vanishing so quickly.
Two things you need to do to fix this:
All code paths through check_collision must write to the 'buff' out parameter. The easiest way to do this is initialize it to 0 in the first line of the function. (Alternatively, if it's intended as an in/out param, then you need to initialize it in the main loop before calling check_collision() )
Make your decision based on the return value of check_collision(), rather than the out parameter. (Or, if that return value really is not important, change the return type of the function to void)
Line 23 in string_lines is missing a comma at the end. Don't think this is your whole issue, but that can't be good either.
You didn't say if you recompiled it separately under each OS (Vista, etc). And if you did recompile, whether same version of compiler was used.
Windows 7 shipped with Visual C++ 2008 runtime.
Windows Vista shipped Visual C++ 2005 runtime.
XP shipped with Visual C++ 6.0 runtime.
Since you compiled the application in Visual Studio 2010, more than likely it was not compiled to target older operating systems.
Try installing the latest runtimes on the machine you are testing with and if it works after doing that, you know to recompile your project to support older operating systems.
http://www.microsoft.com/download/en/details.aspx?id=5555 x86
http://www.microsoft.com/download/en/details.aspx?id=14632 x64
I would like to be able to tell how long it takes to get from power on to windows starting.
Is there a way of determining this retrospectively (ie once windows has started)?
Does the BIOS/CMOS hold a last boot time?
Would it be possible to tell from RDTSC how long a machine has been running for and subtract the windows boot time?
You might try BootTimer or BootRacer to see either of them will do what you want.
I don't believe you can determine this after Windows is started. I'm not aware of any BIOS that stores the last boot time. But on any modern machine, if the time between power on to calling the OS boot loader (essentially the time it takes to run the POST routines) takes longer than a few seconds, something is wrong.
Are you trying to do this programmatically to get the accurate amount of time that the machine has been online and usable? The inaccuracy resulting from the few seconds that POST takes doesn't seem like it would make a significant difference. If you're timing for benchmarking or optimization purposes, either of these two utilities should work for you.
Get the time since power on from GetTickCount(). Then get the timestamp of a file Windows touches at boot (windows\bootstat.dat for example). Code is below. On my machine it says 16 seconds which sounds accurate.
#include <stdio.h>
#include <windows.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <time.h>
int main()
{
struct __stat64 st;
_stat64("c:\\windows\\bootstat.dat", &st);
return printf("%d\n", st.st_mtime - (time(NULL) - GetTickCount()/1000));
}
#include <omp.h>
#include <stdio.h>
int main(int argc, char* argv[])
{
omp_set_num_threads(4);
printf("numThreads = %d\n", omp_get_num_threads());
}
This code prints:
numThreads = 1
This is compiled in Visual Studio 2010 Ultimate. I have turned Project Configuration Properties (All Configurations) -> C/C++ -> Language -> Open MP Support to Yes(/openmp)
I'm at a loss. I've isolated this issue from a larger project where I'd like to use more than one thread.
Any ideas?
omp_get_num_threads – Size of the active team
Returns the number of threads in the current team. In a sequential section of the program omp_get_num_threads returns 1.
http://gcc.gnu.org/onlinedocs/libgomp/omp_005fget_005fnum_005fthreads.html#omp_005fget_005fnum_005fthreads
This means, use this function inside of parallel loop to know how many thread OMP uses.