Weird segfault involving popen

Reply

Join Date: Apr 2004
Posts: 113
Reputation: liliafan is on a distinguished road 
Solved Threads: 2
liliafan's Avatar
liliafan liliafan is offline Offline
Junior Poster

Weird segfault involving popen

 
0
  #1
Nov 20th, 2004
Hi guys

It has been quite a long time since my last post, but I am having some very weird behaviour on a program I am writing and I was hoping to get a little community feedback

I am writing a class that basically opens a pipe to ksh runs a script gets the results and passes it back to the main program, the weird thing is that as the program terminates it segfaults I know it is related to the class that includes popen but I can't figure out why it is happening:

This is the popen class:
cpp
  1. #include <iostream>
  2. #include <cstdlib>
  3. #include <stdio.h>
  4. #include <string>
  5.  
  6. #include "shell_interp.h"
  7.  
  8. using namespace std;
  9.  
  10. Shell_Interp::Shell_Interp()
  11. {
  12. }
  13.  
  14.  
  15. Shell_Interp::~Shell_Interp()
  16. {
  17. }
  18.  
  19. int Shell_Interp::runshellscript(char *filename, std::string& returnme)
  20. {
  21. FILE *kshfd;
  22.  
  23. char line[200]; // Returned values shouldn't be more than char
  24. char *files_to_open;
  25.  
  26. sprintf(files_to_open, "/usr/bin/ksh %s", filename);
  27.  
  28. if( (kshfd = popen(files_to_open, "r")) == NULL )
  29. {
  30. return 1; // Damn file descriptor is invalid
  31. }
  32.  
  33. fgets( line, sizeof(line), kshfd); // Get line not in a loop cause we know the output
  34. std::string return_result(line); // Convert to string to return
  35. returnme = return_result; // Return this
  36.  
  37. pclose(kshfd); // Close file descriptor
  38. return 0;
  39. }

h
  1. #ifndef SHELL_INTERP_H
  2. #define SHELL_INTERP_H
  3.  
  4. #include <string>
  5.  
  6. /**
  7. @author Ben Maynard
  8. */
  9. class Shell_Interp{
  10. public:
  11. Shell_Interp();
  12. ~Shell_Interp();
  13. int runshellscript(char *filename, std::string& returnme);
  14. };
  15.  
  16. #endif

And this is the calling code in the main function (sorry it is very dirty at the moment it is just test code

  1. Shell_Interp my_shell;
  2.  
  3. char *filename;
  4. std::string resulting;
  5. filename = "/home/work/test.sh";
  6.  
  7. std::string getthisdude;
  8.  
  9. int a = my_shell.runshellscript(filename, getthisdude);
  10.  
  11. cout << "Ran shell script to get: " << getthisdude.c_str() << " return was " << a << endl;
  12. my_shell.~ Shell_Interp();
  13.  
  14. return 0;

As it stand the returned string is exactly as expected, it runs everything before this point and everything after this point without a problem, but when it exits I get a segfault, if I remove the popen code no more segfaults so it is within this code here.

Any advice, help, pointers, questions, gratefully recieved.

Thanks

Ben
Application development, webhosting, and much more: www.webcentric-hosting.com
Reply With Quote Quick reply to this message  
Join Date: Jun 2004
Posts: 436
Reputation: Chainsaw is an unknown quantity at this point 
Solved Threads: 10
Chainsaw's Avatar
Chainsaw Chainsaw is offline Offline
Unprevaricator

Re: Weird segfault involving popen

 
0
  #2
Nov 20th, 2004
files_to_open has no space reserved for it. You declared it as a char* but didn't 'new' it. So do one of these two things:

char* files_to_open = new char[ kMaxFileSize ]; // don't forget to delete it!
-or-
char files_to_open[ kMaxFileSize ];
Reply With Quote Quick reply to this message  
Join Date: Apr 2004
Posts: 113
Reputation: liliafan is on a distinguished road 
Solved Threads: 2
liliafan's Avatar
liliafan liliafan is offline Offline
Junior Poster

Re: Weird segfault involving popen

 
0
  #3
Nov 20th, 2004
Originally Posted by Chainsaw
files_to_open has no space reserved for it. You declared it as a char* but didn't 'new' it. So do one of these two things:

char* files_to_open = new char[ kMaxFileSize ]; // don't forget to delete it!
-or-
char files_to_open[ kMaxFileSize ];
Damn you are good lol:

char files_to_open[ kMaxFileSize ];

Causes failure to compile:
shell_interp.cpp: In member function `int Shell_Interp::runshellscript(char*,
std::string&)':
shell_interp.cpp:31: error: cannot convert `char**' to `char*' for argument `1'
to `int sprintf(char*, const char*, ...)'
shell_interp.cpp:33: error: cannot convert `char**' to `const char*' for
argument `1' to `FILE* popen(const char*, const char*)'

However, char* files_to_open = new char[ kMaxFileSize ]; is perfect gets rid of the segfault completely.

I hate to impose further but any chance you could give me an indication as to why this happened? I would like to learn why this works for future reference instead of just that it does Thanks

Ben
Application development, webhosting, and much more: www.webcentric-hosting.com
Reply With Quote Quick reply to this message  
Join Date: Jun 2004
Posts: 436
Reputation: Chainsaw is an unknown quantity at this point 
Solved Threads: 10
Chainsaw's Avatar
Chainsaw Chainsaw is offline Offline
Unprevaricator

Re: Weird segfault involving popen

 
0
  #4
Nov 20th, 2004
It sounds like you changed

sprintf(files_to_open, "/usr/bin/ksh %s", filename);

to

sprintf(&files_to_open, "/usr/bin/ksh %s", filename);

because that would be a char**, not a char*. Possible?
Reply With Quote Quick reply to this message  
Join Date: Apr 2004
Posts: 113
Reputation: liliafan is on a distinguished road 
Solved Threads: 2
liliafan's Avatar
liliafan liliafan is offline Offline
Junior Poster

Re: Weird segfault involving popen

 
0
  #5
Nov 21st, 2004
Originally Posted by Chainsaw
It sounds like you changed

sprintf(files_to_open, "/usr/bin/ksh %s", filename);

to

sprintf(&files_to_open, "/usr/bin/ksh %s", filename);

because that would be a char**, not a char*. Possible?
Strangely enough no I didn't touch the sprintf() I just changed the declaration of file_to_open.

Ben
Application development, webhosting, and much more: www.webcentric-hosting.com
Reply With Quote Quick reply to this message  
Reply

This thread is more than three months old.
Perhaps start a new thread instead?
Message:



Similar Threads
Other Threads in the C Forum
Thread Tools Search this Thread



About Us | Contact Us | Advertise | DaniWeb | Acceptable Use Policy | RSS Feed

©2003 - 2009 DaniWeb® LLC