I am new to pthread_create and posix threads, I tried to develop a multi-thread program using pthread_create, but it fails with return value equal to -1. I tried to search what is this error code, but could not find any? Does anyone know what this return code (-1) means?
According to POSIX programming Manual, the return value for the pthread_create functions is:
If successful, the pthread_create() function shall return zero; otherwise, an error number shall be returned to indicate the error.
And the list of possible errors are non-negative.
But, for IBM z/OS, for example, the return value can be -1:
If successful, pthread_create() returns 0.
If unsuccessful, pthread_create() returns -1 and sets errno to one of the following values:
So, I suggest:
provide more context on what's the environment and standard library you use
check the errno variable - it should contain the error code
Related
To elaborate, I am currently writing a program that requires a function that is provided by the professor. When I run the program, I get a segmentation fault, and the debugger I use (gdb) says that the segmentation fault occurred at the definition of the function that, like I said, was provided by the professor.
So my question here is, is the definition itself causing the fault, or is it somewhere else in the program that called the function causing the fault?
I attempted to find a spot in the program that might have been leading to it, such as areas that might have incorrect parameters. I have not changed the function itself, as it is not supposed to be modified (as per instructions). This is my first time posting a question, so if there is any other information needed, please let me know.
The error thrown is as follows:
Program received signal SIGSEGV, Segmentation fault. .0x00401450 in Parser::GetNextToken (in=..., line=#0x63fef0: 1) at PA2.cpp:20 20 return GetNextToken(in, line);
The code itself that this is happening at is this:
static LexItem GetNextToken(istream& in, int& line) {
if( pushed_back ) {
pushed_back = false;
return pushed_token;
}
return GetNextToken(in, line);
}
Making many assumptions here, but maybe the lesson is to understand how the stack is affected by a function call and parameters. Create a main() function, that call the professor's provided function and trace the code using dbg, looking at the stack.
When a method returns a BOOL and Error at the same time, Is it enough to check for BOOL status or should we add the additional condition for Error as well?
For example, Following method returns a BOOL and error if any.
-(BOOL)canEvaluatePolicy:(LAPolicy)policy error:(NSError * __autoreleasing *)error;
Now should I write
BOOL biometricsAvailable = [context canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error];
available = (error == nil && biometricsAvailable);
or
BOOL biometricsAvailable = [context canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error];
is enough?
It is clearly described in the documentation here; https://developer.apple.com/library/prerelease/ios/documentation/LocalAuthentication/Reference/LAContext_Class/index.html#//apple_ref/occ/instm/LAContext/canEvaluatePolicy:error:,
Return Value
true if the policy can be evaluated, false otherwise.
Parameters
policy
The policy to evaluate.
error
On input, a pointer to an error object. If an error occurs, this pointer is set to an actual error object containing the error information. You may specify nil for this parameter if you do not want the error information.
So, this means that the Boolean return value tells you if the evaluation was successful. And in case that fails, your error object will be set, which will have a description about the failure.
No, checking the return value should be enough. But when NO is returned, you can have a look at the error variable to see why.
Apple have stated that you should check the return value of the method and only when this is NO or nil can you check the error,
since the SDK could put some weird value in the error variable.
See the document Programming with Objective-C - Dealing with Errors
Define "enough". For what?
The contract of the convention is that if there is a problem, NO should be returned and if you passed in an NSError pointer it'll be populated. If you want to do something with the error, you have to check it, but the convention says that there'll never be a case where the error is provided but YES is returned (if YES is returned the pointer shouldn't even be touched), or where NO is returned and there's no error. This convention is everywhere in Cocoa and has been stable for decades, and since Swift just based their error handling on this model, I think this is even less likely to change.
Both cases are different. It Depends on your requirement.
If you use only BOOL then you only get the status of the request. Whether it is failed or succeed and based on that you can perform task.But you won't be able to know what is the error.
To know what exactly the error is you should go with with first method. If you want to know.
Even though the string conversion succeeds, testing errnoreturns a value indicating an error:
#include <stdlib.h>
#include <sys/errno.h>
const char* numberString = "7";
char* endPtr;
errno = 0;
long number = strtol(numberString, &endPtr, 10);
NSLog(#"%ld", number);
if (errno) {
perror("string to integer conversion failed");
}
The output is (on the Simulator, iOS 7)
$ 2014-05-22 09:27:32.954 Test[2144:60b] 7
$ string to integer conversion failed: No such process
The behavior is similar on the device.
The man page for strtol says in a comment:
RETURN VALUES
The strtol(), strtoll(), strtoimax(), and strtoq() functions return the result of the conversion,
unless the value would underflow or overflow. If no conversion could be performed, 0 is returned and
the global variable errno is set to EINVAL (the last feature is not portable across all platforms). If
an overflow or underflow occurs, errno is set to ERANGE and the function return value is clamped
according to the following table.
It's quite unclear what this exactly means for iOS. Any insights here?
Edit:
It turned out that the function call NSLog did set errno. So, #Mat in his answer and comments was spot on, saying that "all bets are off when testing errno AFTER calling an unrelated function (here NSLog).
If no conversion could be performed, 0 is returned
You're not in that case, 7 was returned.
If an overflow or underflow occurs, ... the return value is clamped according to the following table.
You're not in that case either.
So strtol didn't fail. Inspecting errno is meaningless. Function that are documented to set errno on failure will do so, in case of failure. When no failure happened, the value of errno is "morally" undefined. Don't inspect it.
strtol is a special case though. POSIX requires the following:
These functions shall not change the setting of errno if successful.
So your example should be ok. Except that you're calling a function between the strtol call and your inspection of errno. If you're 100% sure that that function will not itself change errno, or call another function that might set it, then you'd be ok in this very specific case (a function documented not to alter errno in case of success - this is not the norm). Apparently that's not the case though. NSLog will very likely use some system calls at some point, and those (in general) have no guarantee of not altering errno.
I wrote my routines for using CDO.Message. It's working long time ago.
But now, in some site they installed a certificate and then the priorly working version is making errors with all calls.
I used simple variants to hold the CDO.Message COM object.
When I used Send method(?) it returns a HResult.
But it's interesting, because the HResult is unusable for get the error code, because the Send is seems to be a real method which makes Exception on problems.
So the result code is -1 if I set to this value before.
I tried to get the last error code with GetLastError. But this is 0.
I can catch the Exception, but it contains only the error message what is:
"The transport failed to connect to the server"
The VB codes can get the error code which could provide extra information about the problem (or not).
Do you know about a technic to get the error code value from Delphi XE3?
It would be better if we had some source code at hand. Specifically the Delphi declaration of the COM interface.
My guess is that the method is declared as safecall. What this means is that the compiler understands that the method is actually stdcall returning HRESULT, and re-writes the parameters to match. If the true COM method returns an HRESULT other than S_OK then the compiler writes code to check for that and convert the error into an exception.
The exception that is raised will be EOleSysError and that has the property ErrorCode which contains the HRESULT that you are looking for.
So, you need to:
Add an exception handler to catch EOleSysError.
Read the ErrorCode property of the EOleSysError exception instance that you catch.
This is all a little bit round the houses. If you'd prefer to avoid exception handling, then you can always re-write the COM interface declaration to be a true stdcall method returning an HRESULT.
Assuming a thread successfully calls pthread_mutex_lock, is it still possible that a call to pthread_mutex_unlock in that same thread will fail? If so, can you actually do something about it besides abort the thread?
if(pthread_mutex_lock(&m) == 0)
{
// got the lock, let's do some work
if(pthread_mutex_unlock(&m) != 0) // can this really fail?
{
// ok, we have a lock but can't unlock it?
}
}
From this page, possible errors for pthread_mutex_unlock() are:
[EINVAL]
The value specified by mutex does not refer to an initialised
mutex object.
If the lock succeeded then this is unlikely to fail.
[EAGAIN]
The mutex could not be acquired because the maximum number of
recursive locks for mutex has been exceeded.
Really? For unlock?
The pthread_mutex_unlock() function may fail if:
[EPERM]
The current thread does not own the mutex.
Again, if lock succeeded then this also should not occur.
So, my thoughts are if there is a successful lock then in this situation unlock should never fail making the error check and subsequent handling code pointless.
Well before you cry "victory". I ended up on this page looking for a reason why one of my programs failed on a pthread_mutex_unlock (on HP-UX, not Linux).
if (pthread_mutex_unlock(&mutex) != 0)
throw YpException("unlock %s failed: %s", what.c_str(), strerror(errno));
This failed on me, after many million happy executions.
errno was EINTR, although I just now found out that I should not be checking errno, but rather the return value. But nevertheless, the return value was NOT 0. And I can mathematically prove that at that spot I do own a valid lock.
So let's just say your theory is under stress, although more research is required ;-)
From the man page for pthread_mutex_unlock:
The pthread_mutex_unlock() function may fail if:
EPERM
The current thread does not own the mutex.
These functions shall not return an error code of [EINTR].
If you believe the man page, it would seem that your error case cannot happen.