Random Segmentation Fault in Gyach-E, Suse 10
 

Hello, I'm getting a seemingly random crash stating a segmentation fault in gyach-e, I installed the suse 9.2 rpm package on their site and everything works perfectly except that I had to disable smileys and delete the QT file in /opt/gnome/share/themes/Qt/gtk-2.0, that stopped many errors but I'm still getting the random segfault. Yast reported no dependency issues. IT works beautifully up until it crashes however. Whats weirder still is that when im viewing someones webcam the gui and messege window will crash but the window with the cam feed stays up and i can still view them.

I dont get any special output from the terminal, it simply says segmentation fault and closes the program.. .

Edit. .

My hardware is as follows. If it matters. .

Dell inspiron 6000
Pent. M 1.6GHz
512MB ram
64mb ATI Mobility x300 w/ 3D enabled!! ^_^

Ok, I'm now getting a segfault in airsnort as well.. .but only when I try to load a pcap file. .
So I ask what could cause a segfault. .I know it has to do with trying to access memory that either doesnt exist or doesnt have permission to? So other than having bad RAM what could be the cause?? I highly doubt I have hardware memory issues as this is a brand new laptop. .or atleast I hope. .Anyone know of a way to remedy segfaults in general?

may be you are running some programs compiled on the wrong version compiler or compiled against the wrong version of glibc or any other library or something causing their relative references in the executable to be off .

Segfaults are very easy to do from a programing point of view so consider all of them to programing errors if you know your system is build correctly.
basically you end up with a pointer that doesn't point to any place in memory
or points to someplace outside of your programs data segment. I guess "noplace/NULL is actually technically someplace "outside" your programs data segment just like any uninitialized random place -- and then you write a value to it -- you get segfault.
as a programmer you hunt this kind of junk down with the dreaded debugger
(if your system has debugging symbols) and you compile the executable with the -g switch then you can run it like
gdb <progname>
then at the (gdb) prompt you type "run" and any command line arguments it needs
then later when it crashes it will spit out some confusing junk
then you can give it the "where" command and it will say even more confusing junk
there are alot more things you can do with gdb to hunt down segfault troubles but is too complicated to go into here

Next time you boot the system, check the grub boot menu and see if the memtest option is there. If so (and I'd bet it is), select that and let it run the complete set of tests. If it passes without any problems, it's easier to say there's no memory problem.

If you see any errors pop up during memtest's run, see if there is a BIOS option that you can change. I have one system that would occasionally have a fit under load. Running memtest showed errors during the block memory move test (test 7, if memory serves). I changed a setting in the BIOS called (something like) "Highest performance" to "disabled" and it passed the memory tests without error. (And there's no noticable performance hit. Well, other than the one that comes from it being a PIII/733.)

Memory problems were, at one time, not as noticable when running Windows. Even loading Linux on a system wouldn't necessarily expose memory problems until you did something pretty intensive like a kernel compilation and, all of a sudden, BAM! A signal 11 error stops the process in its tracks.

Try the memory test and see what happens and post the results.