Steve,
After looking at the source code, I could get a fix for the XS code's
core-dump. The fix in not related to XS. It is more of AIX's usage of shared
libraries. Basically, the XS source dumps core in "av_len(AV * av)" call when
the function body for XS_unpack_charPtrPtr() exported from another shared
library (librepos_ade.so). When I move the code for XS_unpack_charPtrPtr() to
Repos.c then I do not see any core-dump.
Now I am planning to make Repos.so as shared library and all the dependent
libraries as static libraries. I am sure this might not be the best fix but
this works for me.
Steve & Jens, thanks for all your suggestions/comments with my XS problem..
___Nagesh.
"Steven N. Hirsch" wrote:
> On Mon, 10 Dec 2001, Nagesh Ayyagari wrote:
>
> > Hi,
> >
> > Thanks for all your suggestions. I had tried couple of things over the
> > weekend. Now I have few new things on the AIX shared libraries issue. I
> > just want to see if you have any input
> >
> > 1. I tried using Repos.exp generated by XS module. Looks like it works.
> > So I do not have to change the Makfile that is generated by MakeMaker
> > tool.
> >
> > 2. I have modified my test program to call more functions from different
> > shared libraries. They all seem to work, except the
> > XS_Repos_fetch_version() and few similar funcations which gives
> > core-dump. The code-line that might be causing the problem is
> >
> > ======
> > +329 XS(XS_Repos_fetch_version)
> > +330 {
> > +331 dXSARGS;
> > +332 if (items != 7)
> > +333 Perl_croak(aTHX_ "Usage: Repos::fetch_version(handle,
> > commonName,
> > productName, objectIRIDs, branchIRIDs, versionNums, filePathNames)");
> > +334 {
> > +335 #line 227 "Repos.xs"
> > +336 int fetch_status = 0;
> > +337 int prod_name_status = 0;
> > +338 char** fetchVersionErrorsStack = (char **)NULL;
> > +339 OCIEnv* envhp;
> > +340 OCIError* errhp;
> > +341 OCISvcCtx* svchp;
> > +342 #line 343 "Repos.c"
> > +343 db_handle * handle;
> > +344 char * commonName = (char *)SvPV(ST(1),PL_na);
> > +345 char * productName = (char *)SvPV(ST(2),PL_na);
> > +346 char ** objectIRIDs = XS_unpack_charPtrPtr(ST(3));
> > +347 char ** branchIRIDs = XS_unpack_charPtrPtr(ST(4));
> > +348 int * versionNums = (int *)XS_unpack_intPtr(ST(5));
> > +349 char ** filePathNames = XS_unpack_charPtrPtr(ST(6));
> > +350
> > +351 if( sv_isobject(ST(0)) && (SvTYPE(SvRV(ST(0))) ==
> > SVt_PVMG) )
> > +352 handle = (db_handle *)SvIV((SV*)SvRV( ST(0) ));
> > +353 else{
> > +354 warn( "Repos::fetch_version() -- handle is not a
> > blessed SV re
> > ference" );
> > +355 XSRETURN_UNDEF;
> > +356 };
> > +357 #line 243 "Repos.xs"
> > +358 envhp = (OCIEnv*) handle->env_hp;
> > +359 errhp = (OCIError*) handle->err_hp;
> > +360 svchp = (OCISvcCtx*) handle->svc_hp;
> > +361
> > +362 fprintf(stderr, "\n In fetch_version() before set_repos_p_n
> > \n");
> > ====
> >
> > When I pass less than 7 parameters, I get an error from line # 333.
> > However, when I pass wrong db_handle, I get a core dump.
> >
> > I will be looking into the source code for XS_unpack_charPtrPtr() and see
> > if that is causing the core dump.
> >
> > Let me know if you have any know issues with XS_unpack_charPtrPtr().
>
> Nagesh,
>
> At the risk of seeming naive, what is XS_unpack_charPtrPtr()? I don't
> recognize that as being from the Perl API.
>
> Is this an object method, XS support for a tied scalar or what? Can you
> give me a better feel for the overall context?
>
> Steve
