ue_01_z0102 crashing with "alloc error: cbl_util.c" error message

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 18.01

Description:
ue_01_z0102 process is crashing with an "alloc error: cbl_util.c" error message.

In the nov01 ./scratch/run_e_01_z0102.18732 log we were seeing this:

HANDLING DOC NO. - NOV01.002777649 12:12:17
...
alloc error: cbl_util.c size : -1

Thinking this might be a problem with this particular bib record only, I deleted its z07a records. But now we see in the run_e_01_z0102.11468 log that it is just bombing on the next record:

HANDLING DOC NO. - NOV01.002777650 16:01:28
...
alloc error: cbl_util.c size : -1

Resolution:
The problem is the length of the command for base REF_COLL in tab_base. Although it does not exceed 500 characters, it is close to it. When the programs do an internal parsing (adding parenthesis etc...), it overflows.

Changing the the command for REF_COLL, by replacing all the collections xxREF (like ACREF, AKREF, etc...) by ??REF in the command corrected the problem.

In $alephe_tab: Change from:

> REF_COLL Reference Coll NOV01 NOV01 Y wco=(DKARF or ACREF or AKREF or ASIND or ASLIT or ASREF or ASREF or ASREF or ASROV or BCREF or CBREF or COREF or CUREF or DKDRC or DKRAT or DKRD or DKREF or DKRIN or DKRW1 or DKRW1 or DKRW2 or DLREF or DPREF or DSREF or DWREF or HCREF or ITREF or =KCREF or LAREF or LCREF or MCREF or MIREF or MSDES or MSRCD or MSREF or MSTHE or NCREF or PCREF or SAREF or SCMRF or SCREF or SFREF or SFREF or SMREF or TRREF or UKREF) not wst=(suppressed or deleted or circ-created or oclc-del)

to:

< REF_COLL Reference Coll NOV01 NOV01 Y wco=(DKARF or ??REF or ASIND or ASLIT or ASROV or DKDRC or DKRAT or DKRD or DKRIN or DKRW1 or DKRW1 or DKRW2 or MSDES or MSRCD or MSTHE or SCMRF) not wst=(suppressed or deleted or circ-created or oclc-del)
---

From Issue Resolution: The problem was the length of the command in tab_base.eng for one of the bases. Although it did not exceed 500 characters, it was close to it. When the programs did an internal parsing (adding parenthesis etc...), it overflowed.

Development suggested another way to write the command for this base, using wildcards. The customer confirmed both that it solves the problem and that the command logic is maintained.

Article last edited: 10/8/2013