I see a list of Winsock error codes here
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx
But when I call WSAGetLastError() the result is -2147014848 (or 0x80072740)
How do you correlate the two ?
thanks
This is a HRESULT style Microsoft error code. The low 16 bits is the error code. The high bit is set which is the severity bit. That indicates a failure, and of course it makes the value negative if interpreted as a signed 32 bit integer.
The upper 16 bits (minus for the upper 5 bits, which are flags) is a facility code.
See here: http://en.wikipedia.org/wiki/HRESULT
So this is an error, in facility 7, whose number is 0x2740, or 10048.
And that would be (thanks to http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx)
ta daa: {WSA}EADDRINUSE
There you go.
According to Microsoft's documentation for Windows Socket 2,
"[...] a specific error number can be retrieved by calling the WSAGetLastError function [and] a Winsock error code can be converted to an HRESULT for use in a remote procedure call (RPC) using HRESULT_FROM_WIN32."
I agree with #Kaz's answer that the error code you received of 0x80072740 appears to be an HRESULT, however, something feels off here with the sole fact that you are even getting an HRESULT. When calling WSAGetLastError(), you should essentially be getting back a Win32 status code in all cases from my understanding. I don't see any posted code, so I can't be entirely certain you didn't convert the code to an HRESULT first.
However, you are safest using the following statement when retrieving back an Windows Socket API (WSA) error code:
/* A WSA function indicated an error above. */
Result = HRESULT_FROM_WIN32 (WSAGetLastError ());
This is analogous when using the normal function GetLastError(), which returns a definite Win32 status code.
By using this statement, you can guarentee that you are always dealing with an HRESULT. Also, even if WSAGetLastError() returns an HRESULT sometimes, calling the macro function HRESULT_FROM_WIN32 will just return back the same HRESULT unmodified (see actual HRESULT_FROM_WIN32 definition here).
Lastly, when trying to figure out a specific Microsoft Windows specific error code, I recommend using the following error code look-up site: https://errorcodelookup.com/. The error code you provided refers to the error code WSAEADDRINUSE (0x80072740):
"Only one usage of each socket address (protocol/network address/port) is normally permitted."
Related
See the Question in the title:
Runtime error 201 at $0000000100001D42 $0000000100001D42
Is there a way to show the faulty code line instead of the memory address?
Thanks for the Help
Normally, when a run-time error occurs, you are presented with a list of addresses that represent the call stack backtrace, i.e. the addresses of all procedures that were invoked when the run-time error occurred.
This list is not very informative, so there exists a unit that generates the file names and line numbers of the called procedures using the addresses of the stack backtrace. This unit is called lineinfo.
You can use this unit by giving the -gl option to the compiler. The unit will be automatically included. It is also possible to use the unit explicitly in your uses clause, but you must make sure that you compile your program with debug info.
When compiled with -gl, the following output is generated:
Runtime error 255 at 0x0040BDE5
0x0040BDE5 GENERATEERROR255, line 6 of testline.pp
0x0040BDF0 GENERATEANERROR, line 13 of testline.pp
0x0040BE0C main, line 17 of testline.pp
0x0040B7B1
This is more understandable than the normal message. Make sure that all units you use are compiled with debug info, because if they are not, no line number and filename can be found.
I need to understand the difference between both EAGAIN and EWOULDBLOCK as I have seen many source code are checking against EAGAIN only (may be both the codes represent same number, Correct me here.)
My part of knowledge:
For blocking socket if sender buffer is full and receiver is not receiving any data,Sender will get hanged if call send(). This is because once data is read by the receiver the space it was using in the buffer is made available for new data. If your socket is in 'non blocking' mode then the 'send()' will fail with 'EAGAIN' or 'EWOULDBLOCK'.
Are they always the same number or is there any scenario where they need to be treated differently. ?
In short: they're almost always the same value, but for portability it's recommended to check for both values (and treat both values the same way).
For most systems, EAGAIN and EWOULDBLOCK will be the same. There are only a few systems in which they are different, and you can see the list of those systems in this answer.
Even the errno manpage mentions that they "may be the same [value]".
Historically, however, EWOULDBLOCK was defined for "operation would block" - that is, the operation would have blocked, but the descriptor was placed in non-blocking mode. EAGAIN originally indicated when a "temporary resource shortage made an operation impossible". The example used by the gnu documentation is when there are not enough resources to fork(). Because the resource shortage was expected to be temporary, a subsequent attempt to perform the action might succeed (hence the name "again").
Practically speaking, those types of temporary resource shortages are not that common (but pretty serious when they do occur).
Most systems define these values as the same, and the systems which don't will become more and more uncommon in the future. Nevertheless, for portability reasons you should check for both values, but you should also treat both errors in the same way. As the GNU documentation states:
Portability Note: In many older Unix systems ... [EWOULDBLOCK was] a distinct error code different from EAGAIN. To make your program portable, you should check for both codes and treat them the same.
They are functionally the same. The reason for the two different names is historic going back to the 1980s. EWOULDBLOCK was used on BSD/Sun variants of Unix, and EAGAIN was the AT&T System V error code.
For a compiled binary on a particular system the codes should have the same value. The reason both names are defined in include files is for source code portability.
They are the same.
Defined in the include/uapi/asm-generic/errno.h file:
#define EWOULDBLOCK EAGAIN /* Operation would block */
I have a wxWidgets/GTK based application that works well - except for one installation on an Debian Squeeze ARM system. There it crashes when the user just activates the main window of it. To find the reason for that I added a signal handler to the application and use libunwind out of that signal handler to find the source for the crash. During a test that worked fine, when the software writes e.g. to address 0x0 libunwind correctly points me to the function where that happens.
But the results for the system where the crash appears unexpectedly are a bit strange, they seem to happen outside of my application. One crash comes from a function with no name (here libunwind returns an empty string), and one is caused by "malloc_usable_size", a system function which should never die this way.
So...what to do next? All ideas, suggestions or any other hints are welcome since I'm not sure how to contunue with that problem...
Check for buffer overrun or overwriting some memory unexpectedly for any structures, pointers, memory locations for items returned by library functions.
Check for invalid pointer frees in your code for the library allocated pointers that you are using.
May be using valgrind would also help.
From this rpg socket tutorial we created a socket client in rpg that calls a java server socket
The problem is that connect()/send() operations blocks and we have a requirement that if the connect/send couldn't be done in a matter of a second per say, we have to just log it and finish.
If I set the socket to non-blocking mode (I think with fnctl), we are not fully understanding how to proceed, and can't find any useful documentation with examples for it.
I think if I do connect to a non-blocking socket I have to do select(..., timeout) which tells us if the connect succeed and/ we are able to send(bytes). But, if we send(bytes) afterwards, as it is now a non-blocking socket (which will immediately return after the call), how do I know that send() did the actual sending of the bytes to the server before closing the socket ?
I can fall back to have the client socket in AS400 as a Java or C procedure, but I really want to just keep it in a simple RPG program.
Would somebody help me understand how to do that please ?
Thanks !
In my opinion, that RPG tutorial you mention has a slight defect. What I believe is causing your confusion is the following section's code:
...
Consequently, we typically call the
send() API like this:
D miscdata S 25A
D rc S 10I 0
C eval miscdata = 'The data to send goes here'
C eval rc = send(s: %addr(miscdata): 25: 0)
c if rc < 25
C* for some reason we weren't able to send all 25 bytes!
C endif
...
If you read the documentation of send() you will see that the return value does not indicate an error if it is greater than -1 yet in the code above it seems as if an error has occurred. In fact, the sum of the return values must equal the size of the buffer assuming that you keep moving the pointer into the buffer to reflect what has been sent. Look here in Beej's Guide to Network Programming. You might also like to look at Richard Stevens' book UNIX Network Programming, Volume 1 for really detailed explanations.
As to the problem of determining if the last send before close() did the actual send ... well the paragraph above explains how to determine what portion of the data was sent. However, calling close() will attempt to send all unsent data unless SO_LINGER is set.
fnctl() is used to control blocking while setsockopt() is used to set SO_LINGER.
The abstraction of network communications being used is BSD sockets. There are some slight differences in implementations across OS's but it is generally quite homogeneous. This means that one can generally use documentation written for other OS's for the broad overview. Most of the time.
Well.. it's pretty much that, I seem to be getting a "Illegal Seek" error when checking my errno variable. The problem is that I have no idea of what that can mean.
I know sockets are treated like files in unix, but I can't see how can this be related to sockets. What I'm doing exactly is:
int sck = ::accept(m_socket, (struct sockaddr*)&client_address, (socklen_t*)&address_len);
Then I get sck = -1 and errno = ESPIPE
And the weird thing is that it happens randomly. I mean, sometimes the code works fine, and sometimes it just thows an exception. I'm working with threads so that's understandable. But I just would like to know what kind of behaviour makes the accept() call to set errno as ESPIPE so I could check the paramethers for instance.
Thanks
Nelson R. Pérez
The most probable cause is that the m_socket variable is being corrupted. Use strace as #Aidan suggests to see what value is being passed to accept(2), or attach a debugger to the process and set a watchpoint on that memory location.