I'm coding a web server for fun and I'm now trying to make it dynamic.
I need to do the part usually PHP would do in regular web development, be inside the page code and be executed server side while the server runs.
Now, I've been thinking, and reading a bit on this. I could separate it and then invoke the compiler to make that code run, but I've also read that's not a good way to go about it, so I'd like to avoid it.
I thought maybe if I compiled a program that would go with the specific page it was meant to and made it change the page based on arguments and return the page in buffers, it could work, but that just seems cumbersome.
One wouldn't want to include the code for every single page on the webserver because it just doesn't scale well.
I don't believe C++ can do a "CALL" as in batch when the program is running, it would though, I believe, be the ideal solution besides including a file mid program which isn't possible.
I would like to know whether or not there's a way of executing a program or non-included code during runtime and if so how.
You could try dlopen, dlsym, dlerror and dlclose. These allow you to, at runtime, load libraries. Your server could use it to load code which should execute inside a page.
Howto, by Aaron Isotton
Documentation on man7.org
Related
I'm using Rcpp to run C++ code using RGui (version 3.4.1) as a user interface. Quite often I make changes to the C++ code which compile correctly but cause errors (e.g. searching beyond the end of an array) when I run the relevant program in RGui, causing RGui to crash. This is aggravating because I have to re-open RGui, re-open my R script (sometimes with unsaved changes lost), set the working directory again, etc. before I can re-compile the C++ code and run the program in such a way as to find the problem or test amendments. Sometimes it promptly crashes again because I haven't fixed or bypassed the problem.
Is there some way to change the way Rcpp runs such that RGui returns an error message instead of crashing in these sorts of situations?
Briefly:
It is spelled Rcpp. Capital R, lowercase cpp.
Yes, don't have bugs :)
In general, 2. is the only viable answer. If you need a managed language, use R.
If the code takes your environment down, test outside the environment. Seriously. That is for example why I (co-)wrote littler and test "raw code" on the command-line: it can only take the command-line app down.
We do have a feature in eg RcppArmadillo to test for "out of bounds" vector access: use x.at(i,j) which will warn. See http://arma.sourceforge.net/docs.html#element_access
I don't actually know of a way to prevent this apart from more careful programming, and saving before execution. But having done this a few times I have discovered a way to get back at unsaved changes, (at least in windows).
When you get the pop-up that tells you to restart R, you don't do it. You open up task manager and right-click on the process and select 'Create Dump File'. Find this file in explorer and open it with some text editor.
They are very big, and full of all sorts of stuff, but if you use find function to search for some string you know to be in your script, then you can find all the unsaved work. You can then copy and paste this into another file to save.
If you use R-studio instead of R-GUI, it usually manages to look after your unsaved work better.
When running my asmjs\emscripten application, compiled from C++, it has suddenly started to log: "run() called, but dependencies remain, so not running" to the web console, and nothing more happens.
I've added some cout's at the absolute start of my main, but even they aren't reached.
The application executed successfully before, but suddenly this started to happen and I don't know what change triggered this.
Does anyone know how to debug this?
Update
After removing as much source code as I could, this happens as soon as I #include , even due my main simply consists of a single cout.
Ideally you would have the entire environment when it was running in version control, and build every version since to see where it broke.
You might have your code in version control, but perhaps not Emscripten itself. If you've updated Emscripten, this could lead to differences in behaviour. I would try going back to whatever version you used when it was running. Note that sometimes various cache directories survive an Emscripten version change, and might need to be cleared manually (I forgot which exactly).
The dependencies remaining could mean that you are trying to do something before Emscripten has loaded any other files it needs to, say files requested by --preload-file or --memory-init-file. Note that according to https://kripken.github.io/emscripten-site/docs/getting_started/FAQ.html#faq-when-safe-to-call-compiled-functions you should not try to run any Emscripten functions, until the C++ main function has run. To detect this, you can, for example, call your own Javascript function from main (there are other ways).
The fact this wasn't causing a problem before could have been something that seems quite unrelated: a change or update in the web browser, changing limits of concurrent downloads, or a change in the web server this is running from. You could look in the Network tab in the browser to see if anything leaps out at you as being different or suspicious.
However, as main isn't even reached, then it might not be that. I would try commenting out virtually all of your code, and make it so you have practically nothing but a hello-world program. Perhaps you don't have a correct setting in the Module object, or maybe the request for the memory initialization file is failing (you can check in the Network tab in the browser for that one). If your basic hello world program still isn't working, then you could post again, with its code, in a separate question.
This can also happens when the browser runs out of memory. Unfortunately, the browser's memory handling is not in our control so there isn't much you can do beside reducing your payload. This includes code size, preload content size, etc. Basically anything that can reduce the total memory consumption of your program will help fixing this. Browser vendors are constantly working to improve this, but it's going to take a while still.
I think you haven't given enough information to really know for sure. But it might be for instance that your js suddenly crossed some memory threshold which exceeds what the browser wants to allocate to it. You could try reducing the amount of memory used / streaming some assets instead of preloading them / ship less code / use -Os optimization level?
Our app is ran from SU or normal user. We have a library we have connected to our project. In that library there is a function we want to call. We have a folder called notRestricted in the directory where we run application from. We have created a new thread. We want to limit access of the thread to file system. What we want to do is simple - call that function but limit its access to write only to that folder (we prefer to let it read from anywhere app can read from).
Update:
So I see that there is no way to disable only one thread from all FS but one folder...
I read your propositions dear SO users and posted some kind of analog to this question here so in there thay gave us a link to sandbox with not a bad api, but I do not really know if it would work on anething but GentOS (but any way such script looks quite intresting in case of using Boost.Process command line to run it and than run desired ex-thread (which migrated to seprate application=)).
There isn't really any way you can prevent a single thread, because its in the same process space as you are, except for hacking methods like function hooking to detect any kind of file system access.
Perhaps you might like to rethink how you're implementing your application - having native untrusted code run as su isn't exactly a good idea. Perhaps use another process and communicate via. RPC, or use a interpreted language that you can check against at run time.
In my opinion, the best strategy would be:
Don't run this code in a different thread, but run it in a different process.
When you create this process (after the fork but before any call to execve), use chroot to change the root of the filesystem.
This will give you some good isolation... However doing so will make your code require root... Don't run the child process as root since root can trivially work around this.
Inject a replacement for open(2) that checks the arguments and returns -EACCES as appropriate.
This doesn't sound like the right thing to do. If you think about it, what you are trying to prevent is a problem well known to the computer games industry. The most common approach to deal with this problem is simply encoding or encrypting the data you don't want others to have access to, in such a way that only you know how to read/understand it.
Need to profile a daemon written in C++, gprof says it need to terminate the process to get the gmon.out. I'm wondering anyone has ideas to get the gmon.out with ctrl-c? I want to find out the hot spot for cpu cycle
Need to profile a daemon written in C++, gprof says it need to terminate the process to get the gmon.out.
That fits the normal practice of debugging daemon processes: provision a switch (e.g. with command line option) which would force the daemon to run in foreground.
I'm wondering anyone has ideas to get the gmon.out with ctrl-c?
I'm not aware of such options.
Though in case of gmon, call to exit() should suffice: if you for example intend to test say processing 100K messages, you can add in code a counter incremented on every processed message. When the counter exceeds the limit, simply call exit().
You also can try to add a handler for some unused signal (like SIGUSR1 or SIGUSR2) and call exit() from there. Thought I do not have personal experience and cannot be sure that gmon would work properly in the case.
I want to find out the hot spot for cpu cycle
My usual practice is to create a test application, using same source code as the daemon but different main() where I simulate precise scenario (often with a command line switch many scenarios) I need to debug or test. For the purpose, I normally create a static library containing the whole module - except the file with main() - and link the test application with the static library. (That helps keeping Makefiles tidy.)
I prefer the separate test application to hacks inside of the code since especially in case of performance testing I can sometimes bypass or reduce calls to expensive I/O (or DB accesses) which often skews the profiler's sampling and renders the output useless.
As a first suggestion I would say you might try to use another tool. If the performance of that daemon is not an issue in your test you could give a try to valgrind. It is a wonderful tool, I really love it.
If you want to make the daemon go as fast as possible, you can use lsstack with this technique. It will show you what's taking time that you can remove. If you're looking for hot spots, you are probably looking for the wrong thing. Typically there are function calls that are not absolutely needed, and those don't show up as hot spots, but they do show up on stackshots.
Another good option is RotateRight/Zoom.
Ok so I am learning C++ slowly. I am familiar with all the console syntax and everything, but now I'm moving on to windows programming. Now what im trying to do, is create a DLL that I inject into a process, so it's hooked in. All I want the C++ application to do, is have text in it, that says "Hooked" if it's successfully injected, and an error if something wrong happened. Or even if I can do it without a DLL, Just open an executable, and when the certain process I'm trying to hook is opened, the status is changed to "Hooked". Also I have a safaribooksonline.com account so if there is any good reads you would recommend, just write it down. thanks
I think you might be looking at this backwards. In C/C++ an application 'pulls' a DLL in rather than having a DLL 'injected' into an application. Typically for plugins/hooks, there is some mechanism to inform an application of a DLL's availability (often just its presence in a specific directory) and a configuration file or some other logic is used to instruct the application to explicitly load the library, extract a function or two, and call them.
For Windows programming, I'd suggest doing a search for examples of the LoadLibrary() API call. You'll likely find a tutorial or two on how to do it.
If by "hooked" you mean, "have my DLL run in that processes' address space", you want CreateRemoteThread(). This is fairly advanced and difficult to debug, because your bugs make the other program crash. It's how a lot of malware works, by the way.
If you mean "have my DLL get notified of activity in the other process", you want SetWindowsHookEx().
Sounds like you want to inject as soon as the application starts? You can do that with Microsoft's Detours DetourCreateProcessWithDll(). Example here.