BAD_ALLOCATION in SAPTS_SET_DATA_RIW

[Former Member]

Hello All,<br>

<br>

We've the mentioned problem in LiveCache, and unfortunately I've not found any note and information about it. Has somebody ever found similar problem? What's the solution?<br>

Thanks.<br>

Best regards,<br>

Gyorgy Matyas<br>

<br>

<b>######### LCTRC#apo_com_trace_01.txt ###########</b><br>

0x75226172 ######## #!!# Bad Allocation exception in SAPTS_SET_DATA_RIW ##########<br>

0x75226172 # COM build 50011.001 CL 368043 (5.0_REL) on HP IPF<br>

0x75226172 ### return code entry ###<br>

0x75226172 errorcode = -1028000<br>

0x75226172 <<<<<<<<<<<<<<< callstack (please include when contacting BC-DB-LCA): >>>>>>>>>>>>>>>>>>>>>>><br>

0x75226172 stack size: 10, max stack usage in session: 12 (calls), 14608 (bytes)<br>

0x75226172 CS[0]: /LCAPPS/50_REL/7600/hpia64/genopt/sys/wrk/incl/COMBase/api_functor/cbs_api_obj_functor.h: 69 SAPTS_SET_DATA_@<br>

0x75226172 RIW, bytes: 7376<br>

0x75226172 CS[1]: cbs_err_api_functor-COMBase+Release.cpp: 79 TsApiDataSetDataRIWFunctor, bytes: 3896<br>

0x75226172 CS[2]: ts_datahandler-tsdp_lib+Release.cpp: 584 TsDataHandler::setData, bytes: 676<br>

0x75226172 CS[3]: ts_datahandler-tsdp_lib+Release.cpp: 673 TsDataHandler::runPropagation, bytes: -1872<br>

0x75226172 CS[4]: ts_dp_propagation-tsdp_lib+Release.cpp: 76 TsDPPropagation::propagate, bytes: -2000<br>

0x75226172 CS[5]: ts_dp_propagation-tsdp_lib+Release.cpp: 1105 TsDPPropagation::propagateIncreases, bytes: -2128<br>

0x75226172 CS[6]: ts_dp_propagation-tsdp_lib+Release.cpp: 411 TsDPPropagation::distributeIncreases, bytes: -2896<br>

0x75226172 CS[7]: ts_abs_increase-tsdp_lib+Release.cpp: 419 AbstractIncrease::distribute, bytes: -2944<br>

0x75226172 CS[8]: ts_simple_increase-tsdp_lib+Release.cpp: 197 SimpleIncrease::createDownIncInpArray, bytes: -3648<br>

0x75226172 CS[9]: ts_abs_increase-tsdp_lib+Release.cpp: 248 AbstractIncrease::getValueArraysForDisaggregation, bytes: -4592<br>

0x75226172 CS[end] >>>>>>> end of callstack <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<br>

0x75226172 <br>

0x75226172 <br>

0x75226172 <a name="000004TUpn8001nFSzMmV0">000004TUpn8001nFSzMmV0</a><br>

0x75226172 log@20071211-185530 planversion = 000 , client = 700 {U+373030}<br>

0x75226172 (dialog)<br>

0x75226172 <br>

0x75226172 file cbs_api_control-COMBase+Release.cpp, line 111 SAPTS_SET_DATA_RIW: omsTerminate will be triggered:<br>

0x75226172 BAD_ALLOCATION in SAPTS_SET_DATA_RIW<br>

0x75226172 , Operator NEW failed ERROR -1028000 in SAPTS_SET_DATA_RIW (file: /LCAPPS/50_REL/7600/hpia64/genopt/sys/wrk/incl/CO@<br>

0x75226172 MBase/api_functor/cbs_api_obj_functor.h, line: 69): SessionGlobals<br>

0x75226172 stack EMPTY! , max stack usage in session: 12 (calls), 14608 (bytes)<br>

0x75226172 CS[end] >>>>>>> end of callstack <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<br>

<br>

<b>############### KNLDIAGERR ######################</b><br>

1. #!!# Bad Allocation exceptio<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT n in SAPTS_SET_DATA_RIW ##########<br>

1. COM<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT build 50011.001 CL 368043 (5.0_REL) on<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT HP IPF<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT omsTerminate will be triggered:<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT SAPTS_SET_DATA_RIW<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT file: /LCAPPS/50_REL/7600/hpia64/genopt/<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT sys/wrk/incl/COMBase/api_functor/cbs_api<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT objfunctor.h<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT line: 69<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT BAD_ALLOCATION in SAPTS_SET_DATA_RIW<br>

,<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT Operator NEW failed ERROR -1028000 in SA<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT PTS_SET_DATA_RIW (file: /LCAPPS/50_REL/7<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT 600/hpia64/genopt/sys/wrk/incl/COMBase/a<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT pi_functor/cbs_api_obj_functor.h, line:<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT 69): SessionGlobals<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT <a href="lcapo_com_trace_01.txt#000004TU<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT pn8001nFSzMmV0">For details see lcapo_co<br>

2007-12-11 18:55:30 165 ERR 51000 OBJECT m_trace_01.txt</a><br>

2007-12-11 18:55:30 165 ERR 11258 DCOM-DMP Drop all component objects active on session<br>

2007-12-11 18:55:30 165 ERR 11258 DCOM-DMP Drop of component objects done<br>

2007-12-11 18:55:30 165 ERR 51260 HRESULT omsTerminate in SAPTS_SET_DATA_RIW<br>

<br>

<b>################## SM21 ########################</b><br>

BY 2 Database error 600 at EXE<br>

BY 0 > POS(1) Work rolled back: BAD_ALLOCATION in SAPTS_SET_DAT<br>

AB 0 Run-time error "DBIF_DSQL2_SQL_ERROR" occurred<br>

AB 1 > Short dump generated

[Former Member · Accepted solution]

Hi,

which version you used?

look at SAP Note 1050164 - Runtime error while deactivating Planningobject structure

might help you

regards,

kaushal

mark helpful answers

[Former Member]

Hi Gyorgy Matyas,

the error -1028000 indicates that during the execution of an LCA routine a lack of heap memory occurred.

This usually can have two reason:

1) the heap memory configured with the liveCache parameter OMS_HEAP_LIMIT has been reached (if this is the case you should find a output in the knldiag.err file saying 'OMS_HEAP_LIMIT reached' right before the error)

or

2) the heap memory configured with the liveCache parameter OMS_HEAP_LIMIT is not physically available and the LCA routine was not able to allocate memory up to the defined limit and failed.

So maybe you can check on this.

The reason 1) can either be caused by the fact that the OMS_HEAP_LIMIT was set to a too low value, or because the heap consumption is too high.

If you're an SAP customer then I suggest you to open an OSS message on the component BC-DB-LCA to get the problem analyzed.

Regards

Olaf

[Former Member]

Hello Kaushal and Olaf,

<br><br>

Thanks for your fast reply. I'll check the system according your suggestions, than will come back with feedback.

<br><br>

Best regards,<br>

Gyorgy Matyas

[Former Member]

Hello,

<br><br>

So I checked the livecache settings. It seems, that the OMS_HEAP_LIMIT is too low. Its current value is 1048576 (in another system this value is higher). Because this problem occurs often, this parameter should be reduce. Am I right?<br>

<br>@Kaushal<br>

The executed transaction was /SAPAPO/SDP. The SCM SP level is 9. The mentioned note is relevant to the system, but the change of heap limit can solve this issue, can't it?<br><br>

Thanks.<br>

Best regards,<br>

Gyorgy Matyas

[Former Member]

Hi,

liveCache allocates memory for the data cache, for example. Other applications that run on the system also require memory. OMS_HEAP_LIMIT should be configured in such a way that the physical memory is sufficient for the areas that have already been allocated (liveCache + other applications) and for the dynamically allocated area.

look at Note 337445 - liveCache and memory management

also look at following

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/maxdb/oms+heap&;

regards,

kaushal

[Former Member]

Hi Gyorgy Matyas,

the value OMS_HEAP_LIMIT is maintained in KB, means your current value is at ~1GB. In order to avoid the problem the parameter should be increased instead of reduced.

Regards

Olaf

[Former Member]

Hi,<br>

Thanks, I'll check it.<br>

BR, Gyorgy

[Former Member]

Hi Olaf,

<br>

Yes, you're right, it should be increased. It was a mistake, I would like to say same as you. <br>

BR, Gyorgy

[Former Member]

Hi,<br><br>

There's enough free physical memory (18GB from 30GB), so I'll suggest to raise the value of OMS_HEAP_LIMIT.<br>

Thanks for your help.<br><br>

Best regards,<br>

Gyorgy