RE: Regexp datablade problem
> -----Original Message-----
> From: informix-list-bounces@iiug.org [mailto:informix-list-
> bounces@iiug.org] On Behalf Of Doug Conrey
> Sent: Tuesday, May 23, 2006 9:03 AM
> To: Marco Greco
> Cc: informix-list@iiug.org
> Subject: RE: Regexp datablade problem
>
> > -----Original Message-----
> > From: Marco Greco [mailto:marco@4glworks.com]
> > Sent: Tuesday, May 23, 2006 8:36 AM
> > To: Doug Conrey
> > Cc: informix-list@iiug.org
> > Subject: Re: Regexp datablade problem
> >
> > Doug Conrey wrote:
> > > This looks like a very useful tool, but I can?t get the darn thing
> > > working against IDS 10.0.FC4 on AIX 5.3.
> > >
> > > The first problem I had was compiling errors related to strchr ?
> > > apparently on AIX the compiler wants to use a macro for strchr, so
> the
> > > declaration ?extern char *strchr();? caused the compiler to
produce
> > this:
> > >
> > >
> > >
> > > "c/regexp.c", line 715.29: 1506-041 (E) The invocation of macro
> strchr
> > > contains fewer arguments than required by the macro definition.
> > >
> > > "c/regexp.c", line 715.22: 1506-275 (S) Unexpected text ','
> encountered.
> > >
> > >
> > >
> > > I couldn?t find much about this, but given that the compiler is
> using
> > > macros I figured I could comment out the declaration. If I do that
> it
> > > will compile and link without errors.
> > >
> > > I then copy the files around, create the new VPCLASS and register
> the
> > > blade in my test database as per the instructions. All of these
> things
> > > work without errors as well. Unfortunately when I try to use the
> > > regexp_match(lvarchar, lvarchar) function the engine crashes with
an
> > > assertion failure (no exception handler). I turned tracing on and
it
> > > looks like the regexp function is returning successfully ? the
trace
> > > message immediately before the return executes, and even indicates
> that
> > > it has the correct return value. According to the AF file the
thread
> > > causing the problem is my sqlexec thread, executing in the 0th cpu
> vp. I
> > > don?t see much else of use in there.
> > >
> > > I started playing around with the code a little to see if I could
> > > prevent this by returning before it called various things. It
looks
> like
> > > if the code gets into the regcomp function (in regexp.c) it dies,
> even
> > > if I return immediately after the variable declarations in that
> > function.
> > >
> > >
> > >
> > > As a note, I also tried compiling this with gcc. If I do that the
> engine
> > > crashes with a number of these:
> > >
> > >
> > >
> > > rtld: 0712-001 Symbol memcpy was referenced
> > >
> > > from module /usr/informix/extend/regexp.1.0/regexp.bld(),
but
> a
> > > runtime definition
> > >
> > > of the symbol was not found.
> > >
> > >
> > >
> > > Then I tried compiling with the ?bstatic flag, and got something
> new:
> > >
> > >
> > >
> > > 14:52:32 Fatal error in ADM VP at mt.c:12516
> > >
> > > 14:52:32 Unexpected virtual processor termination, pid = 209262,
> exit => > > 0x100
> > >
> > >
> > >
> > > I?m pretty much out of ideas, but this would be such a handy tool
> I?m
> > > hoping someone has a solution. Thanks.
> > >
> > >
> > >
> > > DC
> > >
> > my guess would go as follows - on solaris memcpy and friends are
> declared
> > in
> > string.h, but on aix they are in memory.h. What is probably
happening
> is
> > that
> > the compiler, having not found the prototypes, deems one of said
> functions
> > (not memcpy) to be returning an integer, and truncates the pointer.
> from
> > then
> > on, a segv is just round the corner. try
> >
> > #include <memory.h>
> >
> > at the beginning of the blade
> > also, since you building a blade for a 64 bit engine, I trust that
you
> are
> > doing a cc -q64 -G ... if not, you would be mixing and matching 32
and
> 64
> > bit
> > pointers
> >
> > --
> > Ciao,
> > Marco
> >
>
________________________________________________________________________
> __
> > ____
> > Marco Greco /UK /IBM Standard
> disclaimers
> > apply!
> >
> > Structured Query Scripting Language
> > http://www.4glworks.com/sqsl.htm
> > 4glworks
> > http://www.4glworks.com
> > Informix on Linux
> > http://www.4glworks.com/ifmxlinux.htm
>
> No luck, unfortunately. I added the include to both the sqlfuncs.h and
> the regexp.c files (right next to the includes for string.h), but go
the
> same behaviour. As for the bit mode, I've set the OBJECT_MODE
> environment variable to 64. For the rest, I'm just using the makefile.
> The entire output:
>
> make -f regexpU.mak server
> make[1]: Entering directory `/home/dconrey/regexp.1.0/src'
> cc_r -DMI_SERVBUILD -I./c -I/usr/informix/incl/public
> -I/usr/informix/incl/esql -I/usr/informix/incl -D_H_LOCALEDEF -q64 -o
> AIX-ibmrs6000/regerror.o -c c/regerror.c
> cc_r -DMI_SERVBUILD -I./c -I/usr/informix/incl/public
> -I/usr/informix/incl/esql -I/usr/informix/incl -D_H_LOCALEDEF -q64 -o
> AIX-ibmrs6000/regexp.o -c c/regexp.c
> cc_r -DMI_SERVBUILD -I./c -I/usr/informix/incl/public
> -I/usr/informix/incl/esql -I/usr/informix/incl -D_H_LOCALEDEF -q64 -o
> AIX-ibmrs6000/regsub.o -c c/regsub.c
> cc_r -DMI_SERVBUILD -I./c -I/usr/informix/incl/public
> -I/usr/informix/incl/esql -I/usr/informix/incl -D_H_LOCALEDEF -q64 -o
> AIX-ibmrs6000/sqlfuncs.o -c c/sqlfuncs.c
> makeC++SharedLib_r -p0 -X64 -G -bexpall -bnoentry -o
> AIX-ibmrs6000/regexp.bld \\
> AIX-ibmrs6000/regerror.o AIX-ibmrs6000/regexp.o AIX-ibmrs6000/regsub.o
> AIX-ibmrs6000/sqlfuncs.o \\
> 2> link.errs
> if test -x /usr/informix/bin/filtersym.sh ; \\
> then /usr/informix/bin/filtersym.sh link.errs ; \\
> else cat link.errs ; \\
> fi
> make[1]: Leaving directory `/home/dconrey/regexp.1.0/src'
>
> DC
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
I think I've got this figured out -- I changed the regexp functions
from:
extern regexp *regcomp();
extern int regexec();
to:
extern regexp *regcomp_oci();
extern int regexec_oci();
(and changed all the definitions and calls), and now it works. I'm not a
big fan of C.
Another issue, somewhat related. This module calculates the value of a
clob in order to allocate the correct amount of memory before
manipulating it. It does this with a long type, and the ifx_int8tolong
function. This was returning really silly values, which was causing it
to fail because the server can't allocate 70TB of RAM. I changed it to
ifx_int8toint, then assigned that value to the long, and it works
(assuming my clobs don't exceed maxint).
So if I do this:
ifx_int8toint(&size, &total);
ifx_int8tolong(&size, &test_val);
DPRINTF(TRACE_CLASS, TRACE_MEDIUM, (@@D