Thanks for the feedback. There's no attachment fields on my form, but
there is quite a large diary field (but considerably less than 1mb).
Anyway.. I'm also going to check the tables for a missing record, my
problem is only with the user-tool crashing, it does not affect the
server. I'll post back how it turns out.
[EMAIL PROTECTED] wrote:
**
We had similar problem some years ago when importing arx files, crasch
related to attachments. The workaround was to import without
attachments, and add thoses later separate with the use of 'Update
record'. Never got any further explaination, not a problem anymore as
we now can migrate with data in the forms.
-----Original Message-----
*From:* Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of *McKenzie, James J C-E
LCMC HQISEC/L3
*Sent:* Friday, September 15, 2006 3:42 PM
*To:* [email protected]
*Subject:* Re: request crashing user tool - malloc failed
**
Nyall and Raido:
I'm willing to state that the affected action has a very large
diary or attachment associated with it. If you attempt to export
the record from your database, Oracle can handle the data
collection, but Remedy cannot. Thus, you see a large increase in
memory usage and then the crash. If you care to explore, you can
look at the CLOB storage for that record and find the record is
very large. Don't know how this happens as the limit for a diary
field under Oracle is 1MB of text.
If you need help, I think that I can provide a little bit of it.
James McKenzie
L-3 GSI
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Nyall McCavitt
Sent: Friday, September 15, 2006 5:55 AM
To: [email protected]
Subject: Re: request crashing user tool - malloc failed
Hi,
I have a similar situation with my system:
ARS Server V6.00.01 patch 1497
Solaris 5.9
Oracle 9.2.0.7.0
Each access to the affected ticket causes 100MB of ram to be used
by the arserverd process. When a certain amount of ram has been
used arserverd crashes and armonitor restarts.
SQL trace logs don't show anything but api logging does show an
error. In many cases it is only the values of the Query List that
are returned. No values for any other fields are displayed.
Initially this was showing up as an RPC error/timeout.
I have a ticket open with Remedy Support for 2 weeks now but
nothing that we have tried has traced the problem. We have even
exported the production database and re-imported it into a
different Oracle server and pointed our development Remedy Server
at this copied database. The problem is apparent on both the
production and development servers and it is reproducible 100% of
the time.
If anyone has any ideas I would be grateful.
Thanks.
Nyall
Quoting Raido Oja <[EMAIL PROTECTED]>:
> Hello,
>
> I have discovered 2 requests so far on a regular form, that
cause the
> user tool to crash with 'malloc failed on server' error msg. I
can see
> the requests through a table on some other form, but when searching
> for them the user tool crashes.
>
> When trying to export data the export process hangs when it reaches
> these requests, as does runmacro.exe when exporting from the
command line.
>
> As I have to save the data I am thinking of exporting on the
database
> level, deleting the data and creating a new request afterwards.
Or can
> anyone suggest another way of salvaging these requests?
>
> My system:
>
> ARS 5.01.02 patch 1357
> Windows 2000
> Oracle 9.2.0.3.0
>
> Thanks for any ideas,
>
> Raido
>
>
>
>
_______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
__20060125_______________________This posting was submitted with
HTML in it___
__20060125_______________________This posting was submitted with HTML
in it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
