I am calling an external utility (advzip) from a code to run asynchronous recompression on written data. I use boost::process::spawn to do that:
// std::string f;
auto p=boost::process::search_path("advzip");
if(p.empty()) return;
boost::process::spawn(p,"-q","-z","-2",f);
These subprocesses, however, stay around in zombie state - after they've completed their work - which is not supposed to happen as per boost::process::spawn documentation. Am I doing something wrong?
I am using boost 1.65, running under Ubuntu 18.04.
Related
I have C+ program that compiles to web assebmbly using the emscripten system. I would like to clean up some things, flush files, etc etc. when he page running the program is closed.
in main there is:
emscripten_set_main_loop_arg(onMainLoopTick, arg, 0, 1);
Currently when the page closes the "process" is simply exited and does not continue after the "loop simulator". I figure I need to get an event from the page that will block the main thread until the C++ code process it and cleans up it's mess.
What event should I forward to C++ and how should I use it ?
The first things to know is that there is no native library nor APIs for WebAssembly (I mean..yet, as of MVP. There are native features like threads coming as post-MVP feature). What is means that all system libraries in C++ are implemented by importing emulated JavaScript functions. So if you are looking for native features like detecting closing events, you should check if there is JS/HTML5 APIs that do the similar things.
To see how it works, open generated .wast file and search for import instructions and generated JS files. Also, you may want to search on Emscripten repo directly to check if there is JS/HTML5 bindings available on C++ side, as their documentation is quite large and hard to look through.
Sticking to the point, the HTML5 events that are fired when closing are beforeunload and unload. I would prefer using beforeunload event. Emscripten provides em_beforeunload_callback callback function type and emscripten_set_beforeunload_callback to register in html5.h bindings.
Otherwise, you use them directly. For example:
In C++:
void EMSCRIPTEN_KEEPALIVE clean_stuff() {
// Clean up the mess...
// You should use EMSCRIPTEN_KEEPALIVE or
// add it to EXPORTED_FUNCTIONS in emcc compilation options
// to make it callable in JS side.
}
In JS:
window.addEventListener("beforeunload", function (event) {
// Exported functions are prefixed by an underscore
Module._clean_stuff();
});
I load some textures in asynchronously at the beginning of my game, about 40-50 of them.
vector<string> textureFileNames;
textureFileNames.push_back("textures/particle.png");
textureFileNames.push_back("textures/menu_title.png");
...
textureFileNames.push_back("textures/timer_bar.png");
for (auto fileName: textureFileNames)
{
Director::getInstance()->getTextureCache()
->addImageAsync(fileName, CC_CALLBACK_1(LoadingLayer::textureLoadedCallback, this));
}
My textureLoadedCallback method does nothing funky; at this stage it simply increments a value and updates a progress timer. The callback is called from the main thread by cocos2d-x design, so I don't suspect any problems arise from there.
90% of the time this works fine. But sometimes it crashes in VS2012 midway through loading the textures:
Debug Assertion Failed!
Program: C:\Windows\system32\MSVCP110D.dll
File: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\vector
Line: 1140
Expression: vector subscript out of range
Breaking at this point, I can see that it dies in the internals of vector, specifically the [] operator, and traces back through _Hash to the TextureCache::loadImage() method: auto it = _textures.find(asyncStruct->filename) on line 174 of CCTextureCache.cpp. _textures is defined as std::unordered_map<std::string, Texture2D*> _textures, a standard library unordered map. asyncStruct->filename resolves to the full path and filename of a texture to load.
Using the debugger, I can see that the filename is fine. I can see that _textures already contains the 19 textures before this one that it has processed just fine.
The fact that it seems to just be dying in the midst of the standard library doesn't strike me as right... but I'm unable to determine where CCTextureCache goes wrong. Only that it doesn't always fail, and that it's failing in an asynchronous thread. There's no concurrency bollocks going on with my code (as far as I know).
Is this a cocos2d-x bug, a VS2012 bug or a bug with my code I pasted above?
I think a potential cause could be that the for loop issues like 19 async image loads all at once, which may or may not be supported by that method. Try issuing the next async load only after your texture callback is called. That way no two async loads are performed simultaneously.
I'm currently develop an Objective-C library that links to the MariaDB C connector. I believe there is a problem with the library, though.
Every time I execute my code I get very strange errors on the console. The -(id)init method of my library calls mysql_init(NULL) to initialise the library but as soon as I return from -(id)init I get the following errors in the console:
Object 0x10643df70 of class XXX autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
Thing is, there is no multithreaded code being executed and if I run the same - (id)init without the call to mysql_init(NULL) the errors disappear. I believe the libmariadb library is causing these errors to appear. I don't get why though.
Do I need to build it with any special command line switches? Am I calling the right methods? I obviously used the MySQL online documentation as a guide.
Make sure you add this anytime you have a new thread:
#autoreleasepool {
//enter code here
}
Have you tried latest revision from launchpad?
Also try to build libmariadb with -DUNDEF_THREADS_HACK and
CMAKE_USE_PTHREADS:BOOL=OFF)
I was busy with other stuff for a while. I've since updated MariaDB to the latest version and, as far as I can tell, it works fine.
I'm using the WkHtmlToXSharp wrapper library in my project to generate PDF file from HTML.
I was using this library a lot of times in different PCs and, suddenly, I came across the following problem:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at WkHtmlToXSharp.WkHtmlToPdfConverter.wkhtmltopdf_convert(IntPtr converter)
at WkHtmlToXSharp.WkHtmlToPdfConverter.Convert(String inputHtml)
at WkHtmlToXSharp.WkHtmlToPdfConverter.Convert()
at WkHtmlToXSharp.MultiplexingConverter.b_8()
--- End of inner exception stack trace ---
at Sanford.Threading.DelegateQueue.EndInvoke(IAsyncResult result)
at Sanford.Threading.DelegateQueue.Invoke(Delegate method, Object[] args)
at WkHtmlToXSharp.MultiplexingConverter.Convert()
This seems to be a common problem with this library (I've found some feedback on the web about it - however no fix was provided). BTW, in my case it happens somewhat randomly. I was not experiencing this problem in other dev machines. I wonder if somebody has a fix for it. I also wonder if this is a problem with the wrapper library, if with the WkHtmlToPDF library itself.
Any suggestion? I'm also open to use another converter, as long as it is free and stable and, if possible, without spawning a new process. It must work properly and stable in all Windows versions and do a decent job converting (the HTML to be converted is fixed - contains a few pics and tables and basic CSS).
I would suggest an alternate route: simply use wkhtmltopdf.exe directly, building your own wrapper. They are not very complicated if you have control of the input and then you know exactly how to update it and how the options work. I've never encountered with that problem when using wkhtmltopdf directly (on Win7, Win server 2008 r2, Ubuntu and CentOS). They do spawn process for every conversion though.
For an example, check out the Derp class in another answer of mine regarding wkhtmltopdf. Or try something like the untested code below (your true code will be more complicated, this is just a demo/POC).
var pi = new ProcessStartInfo(#"c:\wkhtmltopdf\wkhtmltopdf.exe");
pi.CreateNoWindow = true;
pi.UseShellExecute = false;
pi.WorkingDirectory = #"c:\wkhtmltopdf\";
pi.Arguments = "http://www.google.com gogl.pdf";
using (var process = Process.Start(pi))
{
process.WaitForExit(99999);
Debug.WriteLine(process.ExitCode);
}
I have a (rather large) application that I have written in C++ and until recently it has been running fine outside of visual studio from the release build. However, now, whenever I run it it says "Unhandled exception at 0x77cf205b in myprog.exe: 0xC0000005: Access violation writing location 0x45000200.", and leads me to "crtexe.c" at line 582 ("mainret = main(argc, argv, envp);") if I attempt to debug it. Note that this problem never shows if I run my debug executable outside of visual studio, or if I run my debug or release build within visual studio. It only happens when running the release build outside of visual studio.
I have been through and put plenty of printfs and a couple of while(1)s in it to see when it actually crashed, and found that the access violation occurs at exactly the point that the value is returned from the function (I'm returning a pointer to an object). I don't fully understand why I would get an access violation at the point it returns, and it doesn't seem to matter what I'm returning as it still occurs when I return 0.
The point it started crashing was when I added a function which does a lot of reading from a file using ifstream. I am opening the stream every time I attempt to read a new file and close it when I finish reading it.
If I keep attempting to run it, it will run once in about 20 tries. It seems a lot more reliable if I run it off my pen drive (it seems to crash the first 3 or 4 times then run fine after that - maybe it's due to its slower read speed).
Thanks for your help, and if I've missed anything let me know.
EDIT: New info
Well I removed the entirity of the function and replaced it with:
IndexedMesh * loadObj(char * objName)
{
ifstream fp_in;
fp_in.open("lol.bmp", ios::in);
fp_in.clear();
fp_in.close();
IndexedMesh * mesh = new IndexedMesh();
printf("finished");
return mesh;
}
I also tried it with "return 0" and "return new IndexedMesh()". It's all fine until you put the ifstream stuff in. I do have 2 other ifstreams open in different functions (accessing completely different files). Could this be the problem?
It actually errors on the return mesh line, (I got the debugger working with the separate release file). It completely nulls the mesh object when it attempts to return it.
The point it started crashing was when I added a function which does a lot of reading from a file using ifstream. I am opening the stream every time I attempt to read a new file and close it when I finish reading it.
Given your description of the code only failing in release mode outside the debugger I'd examine this function for any unset variables. Compiling debug sets variables (or at least it used to) as did running release code in the debugger.
You are probably running over something stored deep in the stack.
I'll bet that if you were to put this at near the top of your code:
int my_main(int argc, char * argv[], char * envp[]);
int main(int argc, char * argv[], char * envp) {
char ** a;
char ** e;
a = malloc(argc+1); // note: you should test the results for NULL
e = malloc(1+count(envp) ) ;// I'm not writing code to count it, but it's easy
int i = 0;
while (argv[i++]) {
a[i] = strdup(argv[i]);
}
a[i] = argv[i]; // argv[i] is NULL and already in a register
// do the same thing for envp
return my_main(argc, a, e);
}
#define main my_main
then whatever it is that is smashing your stack would instead end up smashing this duplicated environment. It's not garenteed, and it is no fix for your problem, but not that difficult.
Thanks very much for your help, I haven't exactly solved the problem but I have managed to evade it. Basically, if I even mentioned an ifsteam (in that function and that function only), the program crashed.
I actually went as far as altering the function to simply declare an ifstream then return 0. I "fixed" it by declaring the ifstreams as pointers and new-ing them. If I deleted the pointer it crashed out again so I had to set it to 0 (leeeeak).
If anyone could enlighten me as to why this occurs, that would be great. While I'm just happy it works now, I'd rather know why..