On Tue, 28 Oct 2008, Glenn Fowler wrote:
what are the total system memory usage stats (ala top) near the time of
the crashes
This is from after the crash before restarting things:
top - 09:50:56 up 27 days, 19:35, 2 users, load average: 0.14, 0.08, 0.11
Tasks: 256 total, 1 running, 255 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32891216k total, 19429892k used, 13461324k free, 369948k buffers
Swap: 67117536k total, 524k used, 67117012k free, 16731820k cached
This is after everything is restarted:
top - 10:26:37 up 27 days, 20:10, 4 users, load average: 9.70, 5.99, 3.25
Tasks: 289 total, 10 running, 279 sleeping, 0 stopped, 0 zombie
Cpu(s): 95.4%us, 2.7%sy, 0.0%ni, 1.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32891216k total, 20851312k used, 12039904k free, 370036k buffers
Swap: 67117536k total, 524k used, 67117012k free, 18107676k cached
linux' malloc memory model is interesting
even though a malloc/mmap/sbrk may succeed
subsequent access to that memory may fail if the system suddenly tightens up
the mode of that failure is a memory access violation
On Tue, 28 Oct 2008 09:40:23 -0400 (EDT) Jeffry R. Abramson wrote:
On Sat, 25 Oct 2008, Henk Langeveld wrote:
Jeffry R. Abramson wrote:
We are seeing some errors where scripts are dying after logging the
following in /var/log/messages:
kernel: script [16631] general protection rip:41c006 rsp:7fff1cf9af60
error:0
kernel: script [30204]: segfault at eb8770 rip 4a8e98 rsp 7fffae5cc680
error 4
Not sure if it is an application problem or a kernel problem or an
interaction between the two. Has anyone else out there seen similar
behavior?
Do your have any idea *where* in the script ksh dies?
Is the behaviour consistent? reproducable?
How often do these scripts run?
The problem might best be described as random and capricious. It is
neither consistent nor reproducable AFAIK. These particular scripts are
daemons that run continuously.
As for your original question:
I sometimes see GPFs when I exit a UWIN shell window under Windows XP.
Of course, windows doesn't call it GPF anymore, but delivers the more
narative:
The instruction at '...' referenced memory at '...'.
The memory could not be read.
I've never bothered digging deeper into it,
as the behaviour is quite haphazard.
Now you see it, now you don't, and it only occurs on exit.
Henk
jeffry r. abramson email: [EMAIL PROTECTED]
prin^h^h^h^hsr.^h^h^htechnical architect phone: (732) 420-4850
at&t solutions cellphone: (732) 241-6784
200 south laurel avenue, room e5-3d24 pager: [EMAIL PROTECTED]
middletown, nj 07748 home: [EMAIL PROTECTED]
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
jeffry r. abramson email: [EMAIL PROTECTED]
prin^h^h^h^hsr.^h^h^htechnical architect phone: (732) 420-4850
at&t solutions cellphone: (732) 241-6784
200 south laurel avenue, room e5-3d24 pager: [EMAIL PROTECTED]
middletown, nj 07748 home: [EMAIL PROTECTED]
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
