Fortran Programming Language :: Segmentation fault caused by write(6,*)


	Segmentation fault caused by write(6,) Hi, My program generate "Segmentation fault". Trying to find reason I found out that this prob;em disappears if I comment a line which performs output on the screen. I looks really strange. Does anybody know why it can happens? Kurda Yon <kurda@yahoo.com> wrote: > My program generate "Segmentation fault". Trying to find reason I > found out that this prob;em disappears if I comment a line which > performs output on the screen. I looks really strange. Does anybody > know why it can happens? Almost an infinite number of reasons. The first thing to realize is that just because the problem went away when you commented out that line, that does NOT* mean the problem is in that line. It has at least reasonable odds that the problem is in a completely unrelated part of the code and that commenting out that line just moved code around in memory in such a way that the symptoms of the problem disappeared. "Segmentation fault" is Unix-speak for memory addressing problems. (That's an approximate translation, but close enough). It can be caused by lots of things. High on the list are exceeding array bounds (do you have bounds checking turned on?) and mismatched argument lists. Because it is generally related to memory addressing problems, it is quite common for the symptoms to change if memory addresses change, which can be caused by trivial changes in completely unrelated parts of the code. It is at least vaguely possible that you don't have screen output set up properly. Usually one doesn't have to do anything much special, but there are environments where a screen output device isn't defined by default. You didn't mention anything at all about your environment, so I can't guess whether you would be in such a situation. If other screen output works, then that's probably not it. -- Richard Maine \| Good judgement comes from experience; email: last name at domain . net \| experience comes from bad judgement. domain: summertriangle \| -- Mark Twain On May 22, 3:40 pm, Kurda Yon <kurda@yahoo.com> wrote: > Hi, > My program generate "Segmentation fault". Trying to find reason I > found out that this prob;em disappears if I comment a line which > performs output on the screen. I looks really strange. Does anybody > know why it can happens? I'd only add if this is the same program as the one w/ the problem in an apparently corrupt array in a function/subroutine that Richard's hypothesis of an indexing error is even higher on the list of likely candidates. Be sure to read the documentation for the compiler to find out how to compile with bounds checking on to catch bounds errors when they occur at run time while debugging/writing new code. Will save untold hours of hunting down problems similar to those you've posted about otherwise. On 22 May, 21:40, Kurda Yon <kurda@yahoo.com> wrote: > Hi, > My program generate "Segmentation fault". Trying to find reason I > found out that this prob;em disappears if I comment a line which > performs output on the screen. I looks really strange. Does anybody > know why it can happens? I'm not sure, but is using "write(6,)" to write to standard output non-portable? Is it better practice to use "write(,)"? Still... using write(6,) on my system works fine without any segmentation fault - so I know I may not be helping. Michal. Nym <neverwillre@gmail.com> wrote: > I'm not sure, but is using "write(6,)" to write to standard output > non-portable? Is it better practice to use "write(,)"? Still... > using write(6,) on my system works fine without any segmentation > fault - so I know I may not be helping. That's a messy area finally at least helped by f2003. (It is messy enough that it can't be completely solved without compatibility problems, but at least it can be helped for future codes). No, using 6 as equivalent to * isn't strictly portable. First, the number 6 is non-portable, although that's the right number for most current compilers. Second, some compilers have fine points of distinction between 6 and . For example, there are compilers where both 6 and appear to go to the same place in simple situations, but they get separated if you do command-line redirection. I personally find that behavior annoying, but other people like it. There are big reasons to want to use a unit number in some codes. (Well, a non-numeric handle would be better in my opinion, but the language doesn't have that; that's an issue that has been proposed/discussed here before). A major reason is that if you use a unit number, you can select the appropriate file just by setting the value of the number. There are many cases where you have some output that you might want to go either to the screen or to some other file. With a unit number, you can just do, for example subroutine sub(lun,...) ... write(lun, ... and it will work in either case, given an appropriate lun. If you have to use , this turns into subroutine sub(lun,...) ... if (some_condition) then write (, ... else write(lun,... This can turn into a big pain. (You might need hundreds of such tests, making the code a mess). Unfortunately, as you note, there is no portable way to know an appropriate unit number for the screen. F2003 adds such a way. But... that was a bit of a side excursion. I doubt that is related to the OP's problem. I won't 100% rule it out, but I'd guess against it. In most implementations, if 6 isn't teh right number for standard output, that would probably just result in writing to a file with a default name like fort.6, or some such thing. -- Richard Maine \| Good judgement comes from experience; email: last name at domain . net \| experience comes from bad judgement. domain: summertriangle \| -- Mark Twain You have to say which compiler you are using and in what mode of use, for what kind of computer, in order to get help. I also suggest you supply a small section of the code around where you suspect you have a problem although the real problem may be elsewhere. Kurda Yon wrote: > Hi, > My program generate "Segmentation fault". Trying to find reason I > found out that this prob;em disappears if I comment a line which > performs output on the screen. I looks really strange. Does anybody > know why it can happens? I've got this problem on a fortran code with Intel fortran and -ipo option set. I never found where was the bug in the code (and I spent a lot of time on this problem!). The code was runing without this option and on the same computer with all the compilers I can use and all options cobination available! It was also runing on other server (RS6000, NEC...)... with different compilers... May be your compiler can also be wrong... Patrick Patrick Begou <Patrick.Be@hmg.inpg.fr> wrote: > May be your compiler can also be wrong... Of course, it may be. Examples come up here regularly. However, it is far more common for people to mistakenly blame the compiler for errors than for it to actualy be a compiler error. I've seen nothing here that particularly suggests a compiler error. That doesn't mean it couldn't be one, but on the whole, I think it a mistake to encourage users in that direction without better evidence. -- Richard Maine \| Good judgement comes from experience; email: last name at domain . net \| experience comes from bad judgement. domain: summertriangle \| -- Mark Twain