Segmentation fault with a file pointer?

Please scroll down to my last post!!

I am compiling sucessfully using gcc 3.3 but on running my program seg faults. I have isolated the problem as being to do with an fprintf line which is fine if I replace fptr with stdout, so I think my fopen line is wrong...

here is a summary of every line containing fptr as graciously supplied by grep:

Code:

---

18-  double x, *cumulative;
19:  FILE *fptr;
20-
--
31-  m = (int) strtol ( argv[2], NULL, 10 );
32:  fptr = fopen ( argv[3], "w" );
33:  if ( fptr == NULL ) {
34-    printf ( "Unable to open \"%s\" to write.\n", argv[3] );
--
155-        fprintf ( stdout, "%d\t%d\t%d\n", i+1, j+1, adjacency[i][j] );
156:        fprintf ( fptr, "%d\t%d\t%d\n", i+1, j+1, adjacency[i][j] );
157-      }
--
161-
162:  fclose(fptr);
163-  return 0;

---

Code:

---

33:  if ( fptr == NULL ) {
34-    printf ( "Unable to open \"%s\" to write.\n", argv[3] );
--
155-        fprintf ( stdout, "%d\t%d\t%d\n", i+1, j+1, adjacency[i][j] );
156:        fprintf ( fptr, "%d\t%d\t%d\n", i+1, j+1, adjacency[i][j] );
157-      }

---

you have your fprintf(fptr.....); within your if braces, so if this evaluates to true then you are trying to write to the file when it hasn't been opened. You need to move it outside the if braces.

hobo

My head is definitly on backwards today, I didn't notice the jump in line numbers so disregard previous answer but you might want to post more code.

Hello :)
First of all, it doesn't really help us you posting only part of your code, as you saw in the previous reply, he got lost in your code because the line jumping.

About you fopen( ), I can't really see something wrong there, perhaps make sure you're calling your program with the correct parameters, and use perror( ) to print your error messages... give a try he'll be more specific then you.

Paste more code... we'll try to help more.
have a nice day.

Sorry I was trying to get down to the heart of the problem - my code has diagnostic statements all over it and would probably stretch the thread this way and that where it is too wide in places. Staggeringly I have implemented this (virtually the same) code in previous programs and not had problems. I have the same header files.

As for posting all my code, I'm not sure that's overly productive as someone typing "you should have done this [CODE]...[\CODE]" is less helpful than "you tend to get a seg fault if such and such, is that happening here?" - I find this approach more useful as it warns of programming problems generally (I can be naive).

Of course, if you think that's tripe, then say so and maybe I will post the code - perhaps as an attachment.

M

Does it create a core dump file?
Try using your debugger to help find the problem.
Is argv[3] a valid address ?

OK yes I may have been misguided in not putting up code. I really can't find the problem even with gdb (although a man with a chisel is not necessarily a sculptor) and I'm getting nowhere...

This is the gdb output (the code is an attachment):

Code:

---

GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(no debugging symbols found)...
Core was generated by `./PB /home/mapmdd/m/bip20.dat 20 2'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libc.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
#0  0xff2c2444 in realfree () from /usr/lib/libc.so.1
(gdb) bt
#0  0xff2c2444 in realfree () from /usr/lib/libc.so.1
#1  0xff2c2cb8 in memalign () from /usr/lib/libc.so.1
#2  0xff2c1dec in _malloc_unlocked () from /usr/lib/libc.so.1
#3  0xff2c1ce0 in _malloc_unlocked () from /usr/lib/libc.so.1
#4  0xff30ee00 in _wrtchk () from /usr/lib/libc.so.1
#5  0xff304b04 in _doprnt () from /usr/lib/libc.so.1
#6  0xff307fc8 in snprintf () from /usr/lib/libc.so.1
#7  0x11b8c in sparse ()
#8  0x11a58 in main ()
(gdb)

---

> I have isolated the problem as being to do with an fprintf line
As with all things relating to memory problems, you have found an effect, not a cause.

If you have electric fence installed (It's a memory debugger), you can do this

Code:

---

gcc -g prog.c -lefence

---

When you run that in the debugger, it should take you to the exact line of code which trashed memory.

I could not compile or run your code, because of all the extra magic in your own personal header file.
I found your code hard to read - especially with those macros renaming variables.

What arguments are you using to run the program?

Here's an example of using gdb to debug a problem:

Code:

---

  root@mypc ~/c/junk
  $ cat junk1.c
  #include <stdio.h>
 
  int main(void)
  {
    char *p  = NULL;
 
    *p = '\0';
 
    return(0);
  }
 
  root@mypc ~/c/junk
  $ gcc -ggdb junk1.c
 
  root@mypc ~/c/junk
  $ gdb a.exe
  GNU gdb 2003-09-20-cvs (cygwin-special)
  Copyright 2003 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "i686-pc-cygwin"...
  (gdb) run
  Starting program: /c/junk/a.exe
 
  Program received signal SIGSEGV, Segmentation fault.
  0x00401078 in main () at junk1.c:7
  7        *p = '\0';
  (gdb)quit

---

And when I run yours under gdb:

Code:

---

  (gdb) run 1 2 1
  Starting program: /c/junk/a.exe 1 2 1
  N=2 and m=1.
  We build an appropriate initial network.
  168042080
  168042096
  Tansferring data to file: "1"
  Data saved to file: 1
 
  Program exited normally.
  (gdb) run 1 2 1
  Starting program: /c/junk/a.exe 1 2 1
  N=2 and m=1.
  We build an appropriate initial network.
  168042080
  168042096
  Tansferring data to file: "1"
  Data saved to file: 1
 
  Program exited normally.
  (gdb)

---

Program works for values of N up to 16 and bums out from 18 onwards... It also works for (seemingly) all values of N if I make fprintf go to stdout instead of fptr. It's rather frustrating...

I forgot about my own little header file - I only use one function from it, one that sums up the elements of an array...

Well post ALL the code, so we can try it.
I'm not going to guess an implementation for the missing functions - who knows, the bug could be in there.

the not-so-magic header file

Tried code on another computer and everything worked fine. I compiled using gcc 3.3 just as before but everything worked fine. Why did this happen?

Dunno
I ran it through electic fence here, and it didn't spot anything wrong.

Quote:

---

Originally Posted by Salem

Dunno
I ran it through electric fence here, and it didn't spot anything wrong.

---

Thanks for trying it. Works OK on my laptop so I'll just have to run the prog on that from now on. It's been a strange and futile affair really, like I alluded to in previous posts I have a few progs that do similar things and use similar code and similar amounts of memory but work fine....

(Will try it through efence or something similar soon though...)