segmentation fault

hello,

i work here with a redesignet SAM9-L9260. It works good. But sometimes, some files will make a segmentation fault. sometimes it's a perl-script and sometimes it's a cgi-program. why? the cgi-program is written in c++ and is not complex. i readed, that "segmentation fault" is like an ram access violation. the tool everytime worked, but since 2 or 3 days it makes very often a segmentation fault.

one time, perl didn't make something. i called it but it outputed nothing.

i looked for free ram. normally there are useed 15mb maximum 20mb ram and there are 40-50 mb free ram. (64MB ram)

why is there are segmentation fault? can it be a hardware defect? and why does the error never shown, but now with the self binary (md5sum checked) it dont works?

sorry for my bad english


best regards
toredo

Originally Posted by toredo hello, why is there are segmentation fault? can it be a hardware defect? and why does the error never shown, but now with the self binary (md5sum checked) it dont works? toredo

yes it can be a hardware defect related to RAM, swap on the disk or CPU error. i would start to test RAM than swap. then check if motherboard is dying or not. if everything shows OK, then check the CPU for running errors (CPU can make mistakes then they are too hot. i'm not sure about embedded systems as they are suppos to be very stable).

however make sure that it's not a programming error like mishandling a pointer and such.

here's some nice read: http://www.faqs.org/qa/qa-673.html

Hello.
First check if you have updated or use a different version of some system depending software.
This means e.g. the case of compiling, yet compiled software.
- is the kernel version the same like the system was compiled with, for?
- is gcc version the same glibc was compiled with.
- ...

Think about if you compiled and installed newer versions of any software.
This means for compilation the use of newer headers and that has to be voided in any case.
So compiling some new versions of software doesn`t matter at all, but installing them, overwrites old headers the system depends on.
Installing new versions works only with binary installations (RPMs) or copy the compiled programs by hand to the places you configured them for. But never compile and install newer versions and then compile on it some software for the same system.
This is more dangerous the most software depends on such a changed header.

This it is in most cases if a system behaves like yours.

thx for the answers

Originally Posted by ozanbaba yes it can be a hardware defect related to RAM, swap on the disk or CPU error. i would start to test RAM than swap. then check if motherboard is dying or not. if everything shows OK, then check the CPU for running errors (CPU can make mistakes then they are too hot. i'm not sure about embedded systems as they are suppos to be very stable). however make sure that it's not a programming error like mishandling a pointer and such. here's some nice read: http://www.faqs.org/qa/qa-673.html

i searched a memory test, but i didn't find one for arm linux. does anyone know one?. i dont use a swap. cpu error, i hope not i tried it on 2 boards and there were sometimes the self error. i think the cpu is ok. but the design of the board is maybe buggy, but i dont hope this too

i'll read the faq, thx for the link.

Originally Posted by bastl Hello. First check if you have updated or use a different version of some system depending software. This means e.g. the case of compiling, yet compiled software. - is the kernel version the same like the system was compiled with, for? - is gcc version the same glibc was compiled with. - ... Think about if you compiled and installed newer versions of any software. This means for compilation the use of newer headers and that has to be voided in any case. So compiling some new versions of software doesn`t matter at all, but installing them, overwrites old headers the system depends on. Installing new versions works only with binary installations (RPMs) or copy the compiled programs by hand to the places you configured them for. But never compile and install newer versions and then compile on it some software for the same system. This is more dangerous the most software depends on such a changed header. This it is in most cases if a system behaves like yours.

i didn't change the system software. i only changed some configurations (sshd, boa...), but i think they don't change something on the system.

Originally Posted by bast - is the kernel version the same like the system was compiled with, for?

yes

- is gcc version the same glibc was compiled with.

yes

i only changed some perl scripts, but they haven't a dependence to the other software.
i didn't install any software or scripts with rpm/deb packages.

but i will remember to you, so i never will install newer software with other old packages


maybe offtopic:

i have an othe rproblem too, but i dont know, has the problem the same source? i dont think, but maybe?

a perl-script made a stack-overflow, there are no recursive functions or something like this. but its a big script so maybe its only a error from the script.
i saw the error, when i used the command dmesg. after this, the process were a dead (zombie) process.


thx 4 help.

Yes, then I agree with, that it could be a hardware defect. Or do you have a more-core CPU? It could be that such interpreters are not thread save on such CPUs. (e.g. in 64 bit mode)

Maybe your BIOS has also some hardware checks that can be enabled. Those checks takes then some time (HD around 1-2 hours possible data loss, RAM about 3 minutes, all other hardware is full checked at boot time).

A other possibility could be that your hardware timings between CPU, FSB and RAM are wrong set up by the BIOS this occurs e.g. on cheep RAM with low latency. Or you've chosen a too fast setup