By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,952 Members | 1,032 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,952 IT Pros & Developers. It's quick & easy.

Problem With fgetc/getc

P: 2
I'm having a bit of a problem running a C program I'm working on (compiled in cygwin). There's a way to go, as I'm intent on making sure each bit works before moving on to the next. As it appears now:

Expand|Select|Wrap|Line Numbers
  1. # include <stdio.h>
  2. # include <string.h>
  3.  
  4. int main(void)
  5. {
  6.     printf("Fine at line 6");
  7.     FILE *source;
  8.     char string1[10];
  9.     int safety=0;
  10.  
  11.     printf("Fine at line 11");    
  12.  
  13.     source = fopen("sourcetext.txt", "r" );
  14.     printf("Fine at line 16");
  15.     string1[0] = getc(source); //using fgetc yields the same result. Removal of this line results in the program running fine.
  16.     printf("%c",string1[0]);
  17.     fclose(source);
  18.     return 0;
  19. }
Of course lines 15 and 16 aren't what I want the program to do, they were just there to help me troubleshoot it. Unfortunately, it seems that if the program contains fgetc or getc it won't run, though cygwin compiles it fine. I get:
Expand|Select|Wrap|Line Numbers
  1. 17 [main] syntax 4100 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
  2. Segmentation fault (core dumped)
The program is called syntax at the moment, and it crashes no matter what the name is, with the name appearing after [main]. The two numbers are different every time I run the program. I got a stackdump file reading:
Expand|Select|Wrap|Line Numbers
  1. Exception: STATUS_ACCESS_VIOLATION at eip=610E67EE
  2. eax=0022D008 ebx=00000000 ecx=611010E8 edx=FFFFFFFF esi=611001A0 edi=00000064
  3. ebp=0022CC58 esp=0022CC40 program=c:\Users\OwnerHP\syntax.exe, pid 4100, thread main
  4. cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
  5. Stack trace:
  6. Frame     Function  Args
  7. 0022CC58  610E67EE  (00000000, 0040201F, 00401050, 00401075)
  8. 0022CCC8  61092D88  (00000001, 61169690, 00FA0090, 0022CC60)
  9. 0022CD78  61006198  (00000000, 0022CDB0, 61005510, 0022CDB0)
  10. 61005510  61004416  (0000009C, A02404C7, E8611001, FFFFFF48)
  11.      17 [main] syntax 4100 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
  12.  
The last time I worked with C code, this spring, I had the same problem, though there the program would run through 30 or so characters in the text file before crashing. It used getc or fgetc, I forget which, also.

What can I do to get this to run, and why is it crashing? I got a similar one to run a while earlier that took the characters retrieved from the file, counted them, and checked to see if there was a certain set, at which point it would stop and print how many characters it saw before the pattern at the end of the file.
Nov 28 '07 #1
Share this Question
Share on Google+
2 Replies


gpraghuram
Expert 100+
P: 1,275
I'm having a bit of a problem running a C program I'm working on (compiled in cygwin). There's a way to go, as I'm intent on making sure each bit works before moving on to the next. As it appears now:

Expand|Select|Wrap|Line Numbers
  1. # include <stdio.h>
  2. # include <string.h>
  3.  
  4. int main(void)
  5. {
  6.     printf("Fine at line 6");
  7.     FILE *source;
  8.     char string1[10];
  9.     int safety=0;
  10.  
  11.     printf("Fine at line 11");    
  12.  
  13.     source = fopen("sourcetext.txt", "r" );
  14.     printf("Fine at line 16");
  15.     string1[0] = getc(source); //using fgetc yields the same result. Removal of this line results in the program running fine.
  16.     printf("%c",string1[0]);
  17.     fclose(source);
  18.     return 0;
  19. }
Of course lines 15 and 16 aren't what I want the program to do, they were just there to help me troubleshoot it. Unfortunately, it seems that if the program contains fgetc or getc it won't run, though cygwin compiles it fine. I get:
Expand|Select|Wrap|Line Numbers
  1. 17 [main] syntax 4100 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
  2. Segmentation fault (core dumped)
The program is called syntax at the moment, and it crashes no matter what the name is, with the name appearing after [main]. The two numbers are different every time I run the program. I got a stackdump file reading:
Expand|Select|Wrap|Line Numbers
  1. Exception: STATUS_ACCESS_VIOLATION at eip=610E67EE
  2. eax=0022D008 ebx=00000000 ecx=611010E8 edx=FFFFFFFF esi=611001A0 edi=00000064
  3. ebp=0022CC58 esp=0022CC40 program=c:\Users\OwnerHP\syntax.exe, pid 4100, thread main
  4. cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
  5. Stack trace:
  6. Frame     Function  Args
  7. 0022CC58  610E67EE  (00000000, 0040201F, 00401050, 00401075)
  8. 0022CCC8  61092D88  (00000001, 61169690, 00FA0090, 0022CC60)
  9. 0022CD78  61006198  (00000000, 0022CDB0, 61005510, 0022CDB0)
  10. 61005510  61004416  (0000009C, A02404C7, E8611001, FFFFFF48)
  11.      17 [main] syntax 4100 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
  12.  
The last time I worked with C code, this spring, I had the same problem, though there the program would run through 30 or so characters in the text file before crashing. It used getc or fgetc, I forget which, also.

What can I do to get this to run, and why is it crashing? I got a similar one to run a while earlier that took the characters retrieved from the file, counted them, and checked to see if there was a certain set, at which point it would stop and print how many characters it saw before the pattern at the end of the file.

HI,
I think the problem is not with getc/fgetc.
After opening the file check for NULL(for the file descriptor) and then do the file operations.
Only if the file descriptor is null then the segmentation fault happens.
I used a different file name for opening and reading.

Raghuram
Nov 29 '07 #2

P: 2
...I had been using a different filename for my earlier test program, I changed the name in the code but forgot to change the file itself...
Thanks, I probably wouldn't have realized on my own: the two names were only one letter apart...
Nov 29 '07 #3

Post your reply

Sign in to post your reply or Sign up for a free account.