hi all!
i have written some uni assignment, a mergeSort algo using multiprocesses.
there is a shared memory created.
the problem is, when i run the App on my pc, it runs perfect.
when i use the uni server is has "Segmentation fault".???

my pc:
Ubuntu 8.10

uni server:
Red Hat Enterprise Linux Server release 5.1 (Tikanga)

thx!

And you seem to expect us to guess your bug from zero information.

From your previous thread, I see you don't follow up very well when someone tries to help you, and I would guess you make pretty random changes to your programs until they seem to work. Probably the tasks are simple enough that the programs are still seriously wrong when they seem to work.

http://www.linuxquestions.org/questi...1/#post3527527

So?

As in your previous thread, you selected some random aspect of the program, with no reason to believe it is related to the problem and make it the subject of the thread.

I assume that means you have the common misconception about segment faults shared by many beginners who post such questions here. You over estimate the importance of the difference between the conditions under which the program segment faults and the conditions under which it doesn't.

A segment fault represents a serious bug in your program. But, especially in simple programs, most serious bugs that cause segment faults don't consistently cause segment faults. There are any number of reasons why the program executing that same serious bug might not segment fault. So to debug it, you should focus almost entirely on the case that does segment fault. Little, if any, information can be deduced from the fact that under other conditions it doesn't segment fault.

The best tool for investigating a segment fault is gdb. Often just finding out the spot in your code where the segment fault occurs is enough to make the cause obvious.

If you know how, and there aren't complicating factors, you can run your program inside gdb and gdb will take control at the segment fault, tell you were it occurred, and let you look around (register and variable values, call stack, etc.).

I rarely debug anything where that approach is practical. A simpler and only slightly less effective method is to enable core dumps, then run the program without gdb until the seg fault creates a .core file. Then open the program and core file in gdb to get most of the same information you could have gotten by running the program inside gdb.

thx alot!

i really do appriciate everybodies help!
i was under pressure submitting my uni task.
don't take it personaly.

the problem eventualy was:
under ubuntu, when i use IORedirection, i opened stdout, somewhere at the end of the code, when i wanted to write.
under redhat, it was segmentation fault. so i opened stdout earlier. it solved the problem. i didn't really understood what was the problem.

thx anyhow.

I usually don't, and I'm glad you didn't either. I realize my answer above was impolite. I don't know a polite way to provide any of the kind of guidance I was trying to provide.

From what you have said, I would guess the problem was not even related to that.

In the complex problems that I work on, we call that kind of solution "stirring the pot". You make a change unrelated to the problem and the symptom happens to go away. You can be pretty sure the problem is still there, only the symptom is hiding.

If your instructor does code review rather than just looking at execution results, maybe he'll tell you what the bug was (and grade you down for turning in a solution with a bug in it).
More likely, you'll "get away with" the error, since you got the symptom to hide. If the objective is the learning rather than the grade, getting away with the error isn't a good thing.