Hello all,
I´m trying to compile a program script customization, but I´m getting this strange message:

See attachment.


I have checked permissions, and no changes have done on the script.

Anybody have seen this message before?

Thank you in advance.

Have you checked the log files to see if there are any other helpful messages? Did you check that /home/mag_pro3 directory? I do not remember ever getting a core dump like this.

Hello Mark,
Yes I have checked on that directory and no core file found.

I´m suspecting that is something SO related. Today I will try to compile that script on a HP9000 server to see if the flavor of the SO have something related.


Thanks.

Sig 11 means, that the program tries to access to a memory address which is not reserved (-> segmentation fault).

Are you allocating memory inside your script or are you using arrays?

(alloc.mem / copy.mem )

It is also possible that you have an hardware failure.

Regards,

Kozure

Hello Kozure,
No, I´m not using arrays on the script.
The error trows when I´m trying to compile it.

But sounds interesting about a memory fault.

Have you faced a similar problem?

Than you in advance.

Never having such a problem up to now.

Maybe the following link is helpful:

http://www.bitwizard.nl/sig11/

If you can find the core file, you can investigate it using the quick guide 1841 "Debugging a Core dump file" from BaaN support.

Regards,

Kozure

Interesting page.
It seems like it is a SO problem related.
I will perform some tests and I will post the results.

Thank you.

This may seem a bit silly, but sometimes, when I get errors when compiling a report, and there is no hint about what is wrong in the compiler output, I simply re-compile in debug mode and it gives usually some more messages that help fix the problem.

Not sure if the same trick will work with a program script - but may be you may want to try.

Seems like you have a bad copy of the compiler binary though. Maybe there is a update available for you at BAAN.

Hello,
Actually I have put a case on Infor. But guess what?
No answer yet.

And yes, I have tried several times to recompile my script, also in debbug mode, but the error are the same.

The only variable is that I have perform a platform migration from HP UX to Intel-Red Hat. My other program scripts compile without problem. This is the only that I have found with problems.

Thanks.

Sorry to wake up such an old thread, but I'm just facing the same situation. One of my scripts won't compile with the same error message. Compiler output looks like this:
.
.
tkkdr0101m01c10:
std_gen6.1 -m -s ptkkdr0101m01c10 -pacc B40CDST -qe /baan/bse/tmp/tmp051315235
bic6.1 -Pvariant=0 ptkkdr0101m01c1g -u -d ottstpstandard -o otkkdr0101m01c1 -f
/baan/bse/tmp/tmp051315234 -pacc B40CDST -qe /baan/bse/tmp/tmp051315236
itkikdstring50( 14): Warning(3): Return value of function 'rdi.domain.string' ignored.
itkkdrobrazek0( 95): Warning(4): A long divided by a long also gives a long.
itkkdrobrazek0( 191): Warning(5): Statement not reached
itkkdrobrazek0( 215): Warning(3): Return value of function 'seq.rewind' ignored.
itkkdrobrazek0( 216): Warning(3): Return value of function 'seq.read' ignored.
itkkdrobrazek0( 217): Warning(3): Return value of function 'seq.close' ignored.
itkkdrobrazek0( 307): Warning(3): Return value of function 'seq.rewind' ignored.
itkkdrobrazek0( 308): Warning(3): Return value of function 'seq.read' ignored.
itkkdrobrazek0( 309): Warning(3): Return value of function 'seq.close' ignored.
bic6.1: core_dumped() signal 11 cwd: '/home/gk'

Have you solved your problem with compiler?

HI grzegorz,
In my case, the problem was in my script code.
On that case, I had a long line with calculations and by mistake I continue with the calculation on the next line and I have a double plus sign. One at the end of the previous line and another at the beginning of the second.

That was strange for me because when I compile that script under HP UX there is no problem.

When I moved to RedHat the problem begun. But definitely It was my mistake.

Hope this helps.

Like mig28mx mentions you might want to start commenting out sections of code to find where the problem might be coming from. Try compiling in debug mode as mentioned above.

Has anybody faced problem on Red Hat when compiling with debug?
We are on latest licd -capable porting set and having issue with some scripts.
Session will hang and eat whole CPU forever...normal compile is ok.

Script we are having issues with is pur4102. It will compile to debug on stnd -level but not on any customized levels. It's very large source to be faultfinded.

BaanIVc4
Portingset 6.1c.19
Red Hat Enterprise Linux Server release 6.4 (Santiago), 2.6.32-358.el6.x86_64
VmWare

Same Problem here.

but very crazy : problem occurs while compiling standard scripts in Custom VRC,
copying standard script to different name, compile works fine.

Here same Details :

Baan C 4c
Portingset 6.1.c.12
SLES 10 SP2
VmWare Environment

Could anybody with this Problem please post the Hardware/Portingset Config ?

any Idea ?

greetzs
Martin

Martin, is it hanging, topping when compiling? And only with debug?
Copying to another name didn't help here...
-Jukka

Martin, is it hanging, topping when compiling? And only with debug?
Copying to another name didn't help here...
-Jukka

no, without debug.
looking to the system log i found a segmentation fault, but why ?

baan05 kernel: bic6.1[30161]: segfault at 0000000000000000 rip 000000000808cfcb rsp 00000000ffb68900 error 6
baan05 kernel: bic6.1[30183]: segfault at 0000000000000000 rip 000000000808cfcb rsp 00000000ffea6960 error 6
baan05 kernel: bic6.1[30218]: segfault at 0000000000000000 rip 000000000808cfcb rsp 00000000ff9cb490 error 6

so, fixed the problem,

seems, that the bic6.1 compiler Portingset 6.1c.12 dont work with virtuell environment.
Replacing the Portingset with 6.1c.19 all works fine.

greetz
martin

Hi Makiju,
Once I have that problem with the same script program.
In my case there were caused by two main factors:
1.- the table of purchase orders lines tdpur041 had a lot of records (around 4 millions).
2.- Database problem.- On that case I had Informix with a serious segmented table.

To fix the first one problem, I had to customize the script in order to pass by some restrictions. The second one was a little harder due to in fact I had to defragment the whole database. But that was with Informix. If you have a powerfull db like Oracle, it offers you a lot of tools in order to identify the bottleneck that causes the slow execution.

Hope this helps.

Hi,
Our problem is related to compile in debug mode...this is not performance related.
Compile works without debug ok. Script is customized. This is pretty hard to solve because we are on latest licmon -porting set. We have upgraded one environment to newer porting set with SLM, but now waiting for licenses which takes ages...ID 7125 should be server license, not user or concurrent. Compile with debug works ok on HP-UX
-Jukka

Have anyone solved that problem. We are facing similar problem. We have migrated from HPUX to linux environemnt to Poritngset6.1c19(b4c4)
I have notcied that problem only appearing with large scripts, where is lot of variables... Compilation in Debug mode simply hang and use 100% CPU.
On HPUx everything was ok.
BR
Tomasz

Have anyone solved that problem? We have laso migrated from HPUX to Linux environment(POritngset 6.1c19 Linux). Compilation simply hang in Debug mode without any information and use 100%CPU. I have noticed that problem is with large scruipts, but the same scripts work without problem on HPUX. Maybe some ulimits...

Only upgrade to newer porting set solved the problem, which is a bit bad solution because of SLM needed...

No, we didn't, at least not in expected way. I refided the script, removed some redundant code and now it's fine. But, old script was also fine and it shoud compile withut problems. Moreover, I'm still able to compile it in our old SCO Unix environment, so it is not a syntax issue.

And, I have also moved some part of my script to a separate library (not function). So, it seems to be a script size related problem.