If one day when using execve you encounter the “no such file or directory” problem, and that the file you tried to launch is really existing and with the good rights, then the problem is coming from the shebang not pointing to a valid interpreter.
Thread programming is fun, starting a tons of process and syncing them on a task, or asynchronously process a bunch of data. But that fun is having a cost: data sharing have to be somewhat locked or well ordered when accessing it. Else you’re going to face some seriously strange situations like time warping variables at the best and big crashes at worse.
On top of that let’s add that the main tools to protect our datas reads / writes by threads can also lead to strange situations where only parts of the code is still running and the rest is in “deadlock” state.
On little examples detecting those deadlocks seems easy, but when scaled to a bigger project/api, it’s a living hell. Tools like valgrind may detect the problems at the cost of big performance loss which may lead to being unable to run into the problem before running into the machine limits.
I was searching for a good ressource to help me in my debugging quest when I stumbled upon that article from Aurelian Melinte which I think is very good (both the author and article): https://linuxgazette.net/150/melinte.html that provide some code samples to superseed the pthread functions with some that will make some checks during the calls.
Microsoft, have you ever done something as bad as your pesky winsock wrapper around classic sockets ? (correct Berkeley’s error code support for FTW)And your way of always reinventing the wheel at your sauce is FUCKING BORING (Hell yeah, why just use open source? Let’s just add a bunch of proprietary shit inside ==> all those boring WINAPIs which are BTW NOT PORTABLE).
It’s BOOOORING, booooring , booooooooring. (Did I add enough ‘o’ ? Because I think you didn’t add enough WSAshit everywhere)
Now I have to make a proper wrapper because you, as a big company, are not able to follow the standards and make things simple and portable. Micro$oft.
From MSDN: “This means, for example, that checking for errors when the socket and accept functions return should not be done by comparing the return value with –1, or seeing if the value is negative (both common and legal approaches in UNIX). Instead, an application should use the manifest constant INVALID_SOCKET as defined in the Winsock2.h header file.”
Hell yeah, let’s review all our calls to check for a specific Windows code….#ShitNumber1
Also: WSAGetLastError() == WSAEWOULDBLOCK , yeah, yeah, why just use common naming convention when you can add WSAshit everywhere ?
Lets not just talk about the FormatMessage function. Using strerror would have been too much for you to handle, it’s a single line func with a single parameter.