Topic: exit signal Segmentation fault (11)

[icpix]

Been getting these for some while. Thought it might be a dying drive or noisy memory but I haven't been able to put any of my fingers on it nor what might be the precipitating circumstances;~/

Here's a couple of examples...
[Mon Feb  7 06:40:28 2005] [notice] child pid 5842 exit signal Segmentation fault (11)
[Mon Feb  7 14:21:34 2005] [notice] child pid 21396 exit signal Segmentation fault (11)

Working sideways is there some way I can determine the owner or whatever of the 'child pid 12345'?

best wishes, Robert

[jackl]

Robert,
The last time I saw segmentation fault messages from an SME box one of the DDR simms was faulty. This problem eventually crashed the server and corrupted the hard disk. Hope this info is of some help.

Jack

[icpix]

Jack

• Huh huh;~/ Had occurred to me too. My rebuild boilerplate notes have been quite copious for some while now.

• Been getting fewer instances after switching off a (mature) installation of PHPA (PHP accelerator) but that's possibly just because of less intensiveness(?).

• Ran the DOS/floppy version of MEMTEST (ie offline) for a long night... to no bad result.

• Ran Charlie Brady's background MEMTEST RPM continuously for a complete week of stress testing - saw two individual errors reported. Ironically there were NO instances of *exit signal Segmentation fault (11)* dynamically reported ie during the stress test. These blots on the landscape are gently returning...

• Googling around reveals that segmentation errors are the result of a programme executing outside its own memory expectations. My thoughts were hoping it was an errant RPM somewhere but I can't think what it might be... So, it's back to quietly wondering about the RAM and the drive;~/

best wishes, Robert

[edb]

Sounds like a defective motherboard to me. Had the same issue once with a dual processor unit. Tried everything you could think of, but no go. Then I happened to have an almost exact match CPUs and MB so I attached the drive to the new system and off she went. Flakey MB

[icpix]

Fair comment. To date my self-built, non overclocked, Asus motherboards have never let me down. However eight or ten years of dust maybe causing tracking, might prove beneficial to get out the vacuum cleaner.

[smeghead]

.. and the meths to clean the contacts (with a cotton bud of course); meths is non residual; electrical cleaning solvent is even better but can be expensive

Also check ALL fans work including the video card if relevant.

Clean out front vents in the case where air is drawn in from; make sure HDD is not overheating.

Living in Perth, Australia I have to be very particular about ventilation & cooling as it can hit 45C on some days.

[icpix]

Strewth! 45C! More amber nectar needed;~)

I only use cotton buds if it's really desperate ie out in the field. Most brands have trace amounts of lanolin (oily substance) impregnated, it's in the manufacturers' odd belief that cotton buds are useful to humans and their skin. I favour the use of an architect's type of eraser/rubber, aka the 'plastic' type, on the contacts. Also making sure I resist the temptation to wipe any (insulating) rubber debris off - NOT with my (oily) fingers.

If it needs cleaning fluid I only ever use isopropyl alcohol [spelling?] and lint-free cloth, but I hardly ever resort to fluids.

Stone cold everywhere... the server's airflow arrangement are unnecessarily excessive so as to avoid unexpected hot spots. All fans running nicely. The large tower case is made of a robustly thick gauge of steel. The SCSI HDD is barely warmer than ambient to the touch.

Video card is an ancient Matrox. It runs cool without the need for an on-board fan or any additional flow arrangements around it.

This server has had a cosseted life and this careful environment has enabled it to return a trouble-free operation... until now;~)

I'm going with the dust vector. It's very very fine dust in there - just right for tracking. I'll polish up the RAM's contacts at the same time.