DSXchange

I am running my first column analysis, The activity status indicated Error Encounted.

When I check the log /opt/IBM/WebSphere/AppServer/profiles/InfoSphere/iasServer-server1.log


*** glibc detected *** /opt/IBM/InformationServer/server/PXEngine/bin/osh: free(): invalid next size (normal): 0x0000000009dd9e0 ***

Any recommendations on how I resolve the issue

Thanking you all in advance

this is a complaint from the C compiler telling you that an attempt to free memory (return it to the operating system) that it had allocated (taken from the OS) failed.

So somewhere you have a memory problem or a configuration problem that led to a memory problem.

You can try just re-running the task. If that does not work, you need to get your tools team involved to check the setup, and it may even lead back to IBM. The most obvious thing to do is re-run it and watch the ram on the machines while it runs.

Have your admin look at the WAS logs as well. There might be something in there too.

I have ensured all the InfoSphere fixpack have been applied (8.7.0.2)

Still cannot complete a column analysis - still getting glibc error

Have anyone else had similar issues with Suse linux installs and found a work around

It is not a glibc error, Ross. It is glibc that is reporting the error. Read the remainder of the message.

I have spent alot of time trying to find a solution so I can progress with cloumn analysis and the data profiling exercise

I will walk away data profiling exercise at this time

or open a PMR with IBM and have them research it.

Your IA setup should not be causing a fault like that.

Most crashes I've seen in the past were do to bad NULL value handling.

This is one of 2 things.
Either you pulled in too much data and ran your system out of memory, or you need your IBM tool suite administrator person/team to look at it.

Stepping away from a problem helps to take a fresh look and all that, but at some point it has to be solved.

I am not an IA guy but my team had similar problems when trying to to analysis on gigantic tables. It was resolved by giving the IA users their own server away from the datastage devs, if I recall. I was only tangentially involved as I wrote a datastage job with a C routine that produced the same info as IA while they worked on the issue.

I Created a new DB2 test table with with 1 row of data (no nulls) - still get the same issue

Any chance you can get version 11.5? It's much more robust (and faster) than version 8.7.

That said, at one of my sites we are successfully performing column analyses against various sources (including DB2) on version 8.5 on AIX.

Another idea is to check "Keep scripts" when you run your IA job. Then you can use DataStage Director to look at the job logs in ANALYZERPROJECT. This may provide useful information, assuming that the job got that far.

Can you please advise the values of your four compiler-related environment variables (such as APT_COMPILER - you know the ones)?

APT_COMPILEOPT = -c -O -fPIC -Wno-deprecated -m64 -mtune=generic -mcmodel=small

APT_COMPILER = g++

APT_LINKER = g++

APT_LINKOPT = -shared -m64

Your compiler options are not at fault. The job crashed and the glibc message was as a result of the crash, not the cause of it. You probably have some data issues with NULLs. Go to your project and maybe use that setting for .... hmmm... old version of null handling... (ok I forget the name off the top of my head).

Just tried with APT_TRANSFORM_COMPILE_OLD_NULL_HANDLING set to true

Same result

Try profiling only some NOT NULL columns.