[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 307
  • Last Modified:

"Accept" - works on some stations, not others

Hi
  I have written a little c++ client/server in linux and everything worked fine. But when I moved the source to another machine and compiled it there, the accept call returns a invalid argument error, when I run and try to connect to the server with a connect call from the client.  If I only move the executable to this machine, it works fine.  So it seems there is something going wrong a compile-time.  I use g++ to compile.

I hope someone can help.  Thanks in advance.

Dadi
0
huxun
Asked:
huxun
1 Solution
 
garbouaCommented:
another linux machine?
g++ -v to see what versions are you running of both machines.

"the accept call returns a invalid argument error,"
I don't understand, if the accept returns an error that would mean it compiles OK and then compiler is NOT an issue, If the error is compilation or link time? then tell us more, line 1--> other machine and versions of compiler. it would really help if you post the actuall error
0
 
huxunAuthor Commented:
Hi ... I figured out how to solve this stupid error.  But I don't understand why it occured.  I have the same version of the compiler on all the machines.  The thing was that when I send the socklen_t argument into 'accept' it ran ok if I compiled at the machine I originally wrote the program, but not if I compiled at some other machine.  Still, I could copy the executable file to this other machine from the original and it would run fine.  So I started commenting alot af stuff out and adding it piece by piece, and on the end I found the cause of the error. This:

char c;
socklen_t fromlen;
.
.
.
accept( s, (struct sockaddr *) &fsain, &fromlen);

had to be changed to this:

socklen_t fromlen;
char c;
.
.
.
accept( s, (struct sockaddr *) &fsain, &fromlen);


I do not understand why this is the case and if someone has a clue, please tell me.
0
 
newmangCommented:
huxun

Without seeing the remainder of your code its hard to offer an opinion. However based on bitter experience I find that in cases where swapping the order of variable declarations "fixes" problems then the real problem lies with the variable being partially over-written by another variable. I think you will find that the second piece of code works because the variable c is not used prior to fromlen being used and the value being loaded into fromlen is longer than socklen_t for some reason. In the first case part or all of fromlen is being over-written by another variable.

I would need to see more of your code to go any further, perhaps you could post the include statements, the variable declarations (if any) after the two you have posted, the code that initialises fromlen (and the declaration of any variables used in this process).

Perhaps you could revert to the original code, compile it on the offending system (with debug) then run it through the debugger watching fromlen at each step to detect the location where this variable gets corrupted.

Cheers - Gavin
0
The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

 
garbouaCommented:
sound like a logical explanation newmang.
0
 
huxunAuthor Commented:
I wrote out the size and location of the variables and they didn't overlap.  Still, do not understand what was going wrong. Guess the compiler is kaput.  It is version 2.96 so ...
0
 
pjb1008Commented:
The fromlen parameter is input and output.
On entry to accept(), it is the size of the address buffer;
on exit it is the size of the address.

Typical usage is:

struct sockaddr_in addr;
sockaddr_t len=sizeof(addr);

retval=accept(fd, (struct sockaddr *)&addr, &len);

Chances are that len wasn't initialised, and you picked up whatever value happened to be on the stack. This will yield different results with different compilers.
0
 
jmcgOwnerCommented:
No comment has been added lately, so it's time to clean up this TA.
I will leave the following recommendation for this question in the Cleanup topic area:

Accept: pjb1008 {http:#7249077}

Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

jmcg
EE Cleanup Volunteer
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now