Fatal ERROR in indirection

[littlecatspb]

Last version, the error is inherited from GT.M V6.3-004

`YDB>w $zv GT.M V6.3-004 Linux x86_64 YDB>s cond="0,1"

YDB>i @cond w ! %YDB-F-KILLBYSIGSINFO1, YottaDB process 547 has been killed by a signal 11 at ad dress 0x00007F01419B0529 (vaddr 0x0000000000000009) %YDB-F-SIGMAPERR, Signal was caused by an address not mapped to an object `

[ksbhaskar]

@littlecatspb It looks like the upstream GT.M team has fixed this and it will be in their next release as GTM-8981. So, when it is released, it will be merged into the YottaDB code base. Is that enough for you (i.e., do you have an adequate workaround) or do you need a fix sooner?

[littlecatspb]

Dear Bhaskar! Thanks for caring ! We have made corrections in our code, but in some cases it is generated dynamically and we can not completely eliminate the occurrence of this error. If you can provide us a patch, we will immediately begin testing it. Sincerely Yours Konstantin.

[nars1]

Konstantin, do you have an M program that dynamically generates these indirection expressions? If so, can you share it with us. The fix is not straightforward and it might take some time but if we have your test case generator, we can run it many times and make sure it works for all generated expressions. Thanks.

[littlecatspb]

Dear Narayanan ! I'm afraid, I can not allocate some finished piece of code that generates the final expression. In this process, user input is also used. In addition, part of the code is written when the system is configured for the end user. An additional complication is the automatic conversion of the source code created in the Intersystems Cache environment. It remains for me to analyze only each specific case of a failure of the qMS system and to single out those constructions that lead to fatal errors. Thank you. PS Now the qMS system consists of more than 700 files and more than a million program lines.

[littlecatspb]

Another example of a real system. I selected one line with an error in a separate program. S qqc=qqc0 D:one I 'one S qqc=$E(qqc_$translate($justify(" ",$S($G(Vo($S($G(qqnump)'="":qqnump,1:99999),qqo,0))'="":Vo(qqnump,qqo,0),1:$G(^Q(1,"CxObj",qqo,"X50"),255)))," ",$select(($zchset="UTF-8"):$char(65535),1:$char(255))),1,$S($G(Vo($S($G(qqnump)'="":qqnump,1:99999),qqo,0))'="":Vo(qqnump,qqo,0),1:$G(^Q(1,"CxObj",qqo,"X50"),255))+1) If gtm_chset=M, The zlink "xL.m" completes without errors and generates .o file. But if gtm_chset=UTF-8, we have: At column 214, line 1, source module /opt/1/utf8/xL.m %GTM-E-INVDLRCVAL, Invalid $CHAR() value 65535 %GTM-F-GTMASSERT2, YottaDB r1.10 Linux x86_64 - Assert failed /home/ak/Projects/new/YottaDB/sr_port/emit_code.c line 1158 for expression (FALSE && ct->opcode) The first error is correct. However, GTMASSERT2 causes the process to abort. Best regards. Konstantin.

[nars1]

Konstantin, thank you for the additional test case. Unfortunately, the fix is not straightforward. We will let you know when we have an update. Sorry I don't have a better answer for you at this point.

[littlecatspb]

Hi Narayanan Don't worry ! We understand the complexity of the problem and are ready to help if we can ! Konstantin.

[nars1]

Konstantin, now that GT.M V6.3-005 is released, I ran your examples. Your first one that produced a KILLBYSIGSINFO1 error works fine with V63005. But your second example that produces a GTMASSERT2 error continues to do so even in V63005. So it would be better if you can create a new issue for the GTMASSERT2 error. I will close this issue (#258) once V63005 is integrated into the YottaDB mainline. Thanks.

[littlecatspb]

Dear Narayanan ! Thank you for the good news ! I'll add code from 6.3-005 to our repository and we'll start testing. Best regards. Konstantin.

[nars1]

GT.M V6.3-005 is now integrated into the YottaDB master branch. And that has the fix for #258 so closing it. A separate issue (#329) has been created for the GTMASSERT2 error.

[littlecatspb]

Thanks for your work !