I am working on a custom made FTP application. The application is behaving erratically for the "ls" command. Wild card character passed to the "ls" command (like "ls *temp") is giving inconsistent results. On debugging I have found that the "ls" command is implemented as shown below in the code of the ftp application,
--------------------------------
FILE* fin;
char line[1024];
.....
.....
//line will contain something like "/bin/ls -l *temp" at this point
fin = popen (line, "r");
//fin is used to get the result of the ls command...
...
//sockets are used to send the data to the client side
---------------------------------

The problem is that "line" gets truncated to "/bin/ls" just after the call to popen. So the result is, sometimes all the files are listed, sometimes nothing at all. If I hard code the value of "line" while calling popen (like popen ("/bin/ls -l *temp", "r") ), the application just gets killed.

Also, socket creation is also failing mysteriously in some cases. While debugging I found that the application is getting some junk IP (0.0.0.100 : 20) for creating the socket and hence it is failing. This behaviour is totally inconsistent and is not reproducible all the time.

The code works fine in AIX. The problem seems to be in Solaris only. There are some subtle differences in the application running on AIX and Solaris plateform. But the code where I found the bug is common to both the plateforms.

Can anyone give me any idea how to go ahead to solve this problem?
 

Can you show the code before popen(). the signature for popen is

FILE* popen( const char * , const char *);

Since it takes only const char * there is no way the popen command can change the contents of what is being passed. We need to make sure that 'line' is valid before calling popen - maybe printf before and after popen would help checking that.
 

Agreed that popen cannot modify "line". But somehow that is what is happening. We cannot use printf here as the application is running as a deamon. I have called a function just before and after popen that will do the task of printf but it will write to a file. The code snippet is like,

...
...
gen_log("Value of line is %s", line); //10
popen (line, "r"); //11
gen_log("Value of line is %s", line); //12
....
....

At line 10 the value of line is "/bin/ls -l *temp" (lets assume we passed *temp as the argument to ls).
At line 12 the value of line is "/bin/ls". The rest gets truncated. Again if we hard code the value of line, the application just crashes.
 

Are you sure your gen_log fn doesn't spoil line. Check it by calling gen_log twice before popen and running it a few times as you say the problem occurs occasionally.
 

I am pretty sure gen_log() is not modifying "line". It is a generic fn. we use in most of our applications for generating error logs. I have tested it. It is not modifying "line".
 

If you're sure gen_log is fine, I suggest u take a copy of line in a another array and pass that to popen.

like ..

char tempLine[200];
strcpy( tempLine , line );
gen_log( both line and tempLine )
popen( ..)
gen_log( again both);

This might solve the problem if line is pointing to a location that was created as a temporary in a previous expression.

I still feel you must call gen_log twice and run it a few times , as u never know . There could be a dormant problem in gen_log implementation.
 

I have tried copying "line" to another variable and passing it to popen. I have tried printing "line" and the temp variable also. I have even tried printing "line" twice by calling gen_log() also. But still, only the variable that is passed to popen is getting corrupted.

Also, why is the application failing when we hard code the command passed to popen (line popen ("/bin/ls -l", "r") ).
 

I have finally figured out the problem. While compiling we were using some custom made libraries. Now in these libraries somewhere someone had implemented his own version of popen. Our call to popen was getting linked to that implementation, which incidently was buggy. Incorrect order of linking of the libraries in the makefile was resulting in all these funny behaviour of the application.

Thanks a lot to all the people who have wasted a lot of there time to help me out.

Have a Unix Problem
Do you have a UNIX Question?

Unix Books :-
UNIX Programming, Certification, System Administration, Performance Tuning Reference Books

Return to : - Unix System Administration Hints and Tips