> Hi all,
> the last weekend we have upgraded Production environment from ARS 4.0.3 to
> 5.1.2 and Informix 7.30 to 9.30 over Solaris 2.8, but we have had daily
> ars
> server crashing with signal 11(Segmentation violation).
> Yesterday afternoon i have applied to our Production environment the
> latest
> ars server 5.1.2 patch(#1267).
> We have an average of 130 User conected to ARSserver ussing heavy Trouble
> Ticket application.
> This morning arserver patch 1267 crash again with signal 11 "Segmentation
> Violation:
>
> "Thu Dec 4 12:47:16 2003 0 : AR System server terminated when a
> signal/exception was received by the server (ARNOTE 20)
> Thu Dec 4 12:47:16 2003 11"
>
> Because, a "segmentation violation fault" results when a process overflows
> its stack. The kernel recognizes the violation and can extend the stack
> size, up to a configurable limit.
> But in a multithreaded environment like ARS 5.1.2, the kernel does not
> keep
> track of each user thread's stack, so it cannot perform this function. The
> thread itself is responsible for stack SIGSEGV (stack overflow signal)
> handling. (The SIGSEGV signal is sent by the threads library when an
> attempt
> is made to write to a write-protected page just beyond the end of the
> stack.
> This page is allocated as part of the stack creation request.)
>
> We are monitoring memory usage by arserver process, specifically when
> arserverd(PID=6102) get a new memory segment(SZ-> ps -ly -p 6102) we are
> seeing that arserverd never free memory allocated, nevertheless we think
> that if arserverd pass over share memory allocated Segments(SEGSZ->ipcs
> -mb)
> for arserverd process(m 12 0x790007a3 --rw-rw---- root other 275564),
> arserverd die with SIGSEGV signal.
>
> For example, in order to show how arserverd increase memory allocated, we
> import an Active Link over Producction environment and we have saw how
> arserverd increase from "94472" to "124056" memory Segmnet Size:
>
> A)INITIAL CONDITION: "Fri Dec 5 12:10:09 CLST 2003"
> [calaf:root:/home/users/boleta/AMR/Upgrade512] ipcs -mb
> IPC status from as of Fri Dec 5 13:05:10 CLST 2003
> T ID KEY MODE OWNER GROUP SEGSZ
> Shared Memory:
> m 1000 0x52564801 --rw-rw---- root informix 184549376
> m 1001 0x52564802 --rw-rw---- root informix 123731968
> m 1002 0x52564803 --rw-rw-rw- root informix 2097152
> m 503 0x52604801 --rw-rw---- root informix 132120576
> m 504 0x52604802 --rw-rw---- root informix 123731968
> m 505 0x52604803 --rw-rw-rw- root informix 1048576
> m 7 0x780007a3 --rw-rw---- root other 20
> m 12 0x790007a3 --rw-rw---- root other 275564
>
> [calaf:root:/home/users/boleta/AMR/Upgrade512] ps -ly -p 6102
> S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD
> O 0 6102 6650 2 67 20 77264 94472 ? 72:02
> arserver
>
>
> B) AFTER we HAVE IMPORTED A NEW ACTIVE LINK: "Fri Dec 5 12:55:01 CLST
> 2003"
> ----------------------------------------
> 6102: /home/ars5.1.2/calaf/bin/arserverd -s calaf -i
> /home/ars5.1.2/calaf -l
> Address Kbytes Resident Shared Private Permissions Mapped File
> FF3A0000 8 8 8 - read/exec libw.so.1
> FF3B0000 160 160 160 - read/exec ld.so.1
> FF3E6000 16 16 - 16 read/write/exec ld.so.1
> FFBE8000 32 32 - 32 read/write/exec [ stack ]
> -------- ------ ------ ------ ------
> total Kb 124056 109896 43216 66680
>
> [calaf:root:/home/users/boleta/AMR/Upgrade512] ps -ly -p 6102
> S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD
> S 0 6102 6650 0 41 20106904 124056 ? ? 80:10
> arserver
>
> C) ACTUAL STATUS: "Fri Dec 5 15:39:09 CLST 2003"
> total Kb 139120 120080 11136 108944
> S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD
> S 0 6102 6650 2 41 20117200 139120 ? ? 151:32
> arserver
>
>
> IF ANYBODY HAVE SOME EXPERIENCE THAT SHARE WITH ME, I?LL REALLY
> APPRECIATE.
>
> Best regards,
> Victor