If anyone else runs into this, I was able to work around this issue on
Solaris using the libumem memory management libs instead of the
default libC memory management libs.
This can be done by setting the following environment variable in the
arsystem script prior to armonitor being started:
LD_PRELOAD=libumem.so
This causes a slightly larger memory footprint.
Axton Grams
On 10/24/06, Jarl Grøneng [EMAIL PROTECTED] wrote:
Yes, had the same on a server ugraded from 5.1.2 to 7.0.1 running on
solaris and oracle.
The last action in sql log was a select against the Role form.
The last action when truss'ing the arserverd was something about
display properties.
However, when doign the upgrade again and then from 5.1.2 to 6.3, and
then to 7.0.1, then the server crash was gone.
The server has several forms with web fixed view.
--
Jarl
On 10/23/06, Axton [EMAIL PROTECTED] wrote:
Has anyone received an error along these lines when starting ARServer 7.0.01?
Mon Oct 23 14:38:18 2006 390600 : AR System server terminated when a
signal/exception was received by the server (ARNOTE 20)
Mon Oct 23 14:38:18 2006 11
Timestamp: Mon Oct 23 2006 14:38:18.9069
Thread Id: 4
Version: 7.0.01 200609271856 Sep 27 2006 19:28:30
ServerName:
Database: SQL -- Oracle
Hardware: sun4u
OS: SunOS 5.9
RPC Id: 0
RPC Call: 0
RPC Queue: 390600
Protocol Version: 12
Client IP Address:
Logging On: API Escalation Filter SQL User Thread
Stacks:
/prod/sys/remedyb/bin/arserverd:DumpStackTrace+0x88
/prod/sys/remedyb/bin/arserverd:SignalTrapProc+0x160
/usr/lib/libthread.so.1:0x15bac
/usr/lib/libthread.so.1:0xf804
/usr/lib/libthread.so.1:0xf9b4
/usr/lib/libc.so.1:0x4762c [ Signal 11 (SEGV)]
/usr/lib/libc.so.1:0x47100
/usr/lib/libc.so.1:malloc+0x20
/prod/sys/remedyb/bin/arserverd:MallocLob+0x110
/prod/sys/remedyb/bin/arserverd:LoadFieldIntoValue+0x428
/prod/sys/remedyb/bin/arserverd:LoadDisplayInfoList+0x46c
/prod/sys/remedyb/bin/arserverd:LoadInitialSchemaInfo+0x5d0
/prod/sys/remedyb/bin/arserverd:InitializeServerCache+0xec
/prod/sys/remedyb/bin/arserverd:WorkerThread+0x230
/prod/sys/remedyb/bin/arserverd:RestartableThreadMain+0x60
/prod/sys/remedyb/bin/arserverd:UnixThreadStartRoutine+0xe8
/usr/lib/libthread.so.1:0x15854
This happens at startup time, so the server never comes up completely.
Environment Info:
- Solaris 9 (en_US.UTF8)
- Remote Oracle 9i (UTF8)
- Oracle 10g client ()
- ARServer 7.0.01
The arsql.log shows the following as the last select statement during
the attempted startup:
SELECT schemaId,fieldId,vuiId,propShort,propLong FROM field_dispprop
ORDER BY 1 ASC,2 ASC,3 ASC
arthread.log shows the following:
*/ Thread Trace Log -- ON
*/ Limits found: current rlimit=4096 - max rlimit=4096
*/ Thread Id 2 (thread number 0) Thread Manager started.
*/ Thread Id 3 (thread number 1) timed call thread started.
*/ Thread Id 4 (thread number 2) on ADMIN queue started.
*/ Thread Trace Log -- OFF
None of the other logs are written to.
There is no core file created.
One of the following actions may have led to the unstartable application
server:
- Import view defs from 6.0.1 (web fixed)
- Import workflow containing direct sql workflow
- Copy views from web fixed to standard
- Delete web fixed views
- Alter the query field (fid 40076) on FB:Variable (change length from
255 to 3999 chars)
- Applied custom CSS tags to fields in the admin tool using the field
properties
- hide the toolbar
- remove the preferences table label from table fields
- hide the toolbar for forms for web mode
Has anyone else performed any of the above actions on a 7.0.01 server
and experienced these issues afterwards? Also, if you have performed
any of the above actions and have not had these issues, that info
would be helpful as well.
This server was working fine all last week, but something happened
between the last good start and the bad start, which has to be one of
the above actions. Please share what you can.
Thanks,
Axton Grams
___
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
___
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers
Are
