«

Hello,

We've hit a problem where we've started getting an error from mod_perl about
undefined subroutines. I know for a fact it is defined, but we've been
unable to trace the cause of the error.

The error seems to be perl 5.8.4 and mod_perl related (both 1 and 2), but
only on linux (we have 4 Solaris 9 systems running perl 5.8.4 not having
issues).

This is but one of meany errors:

error_log:[Sun Jun 27 10:25:49 2004] [error] Undefined subroutine
&gccDispCustomAcctData::CS_Get_Account_Data called at
/opt1/prod/http/cgi-bin/bus/srv_cs_ntt/gccDispCustomAcctData.pm line 182,
<DATA> line 225.\n

I checked gccDispCustomAcctData.pm, and it gets CS_Get_Account_Data from
gccGetAccountData.pm, which is "used" in gccDispCustomAcctData.pm, and is
properly exported.

We initially got this error on a test linux server running RedHat 7.3, which
we had upgraded perl to 5.8.4 and installed Apache2 and mod_perl2 for
testing. We gave up on that and grabbed a Sun box that was already loaded,
because we assumed that that test box was just such and old and abused OS
load that it was naturally going to give problems. Now we have upgraded a
linux box to Fedora C2, installed 5.8.4, apache 1.3.31 and mod_perl 1.29,
and we get the errors.

I hope I'm making sense. The breakdown basically is:

Same machine (Dell 1550, before and after reloading OS):
RedHat 7.3, perl 5.6.1, apache 1.3.29, mod_perl 1.27 - *NO ERROR*
Fedora Core 2, perl 5.8.4, apache 2, mod_perl 1.99_14 - *ERROR*

Two other machines:
RedHat 7.3, perl 5.8.4, apache 1.3.31, mod_perl 1.29 - *ERROR* (Dell 1650)
Solaris 9, perl 5.8.4, apache 2, mod_perl 1.99_14 - *NO ERROR* (ultra60)

Using exact same versions of the code on all instances.

It always hits on the same functions as undefined (varios functions,
different files). If I try an older version of the code it picks a
different set of functions to always hit on for the error.

Any help would be greatly appreciated.

Dan
dburke210 (at) comcast.net

In article <BPOdnSFE5NeYk0LdRVn->, "Dan Burke"
<> wrote:

> error_log:[Sun Jun 27 10:25:49 2004] [error] Undefined subroutine
> &gccDispCustomAcctData::CS_Get_Account_Data called at
> /opt1/prod/http/cgi-bin/bus/srv_cs_ntt/gccDispCustomAcctData.pm line
> 182, <DATA> line 225.\n
> I checked gccDispCustomAcctData.pm, and it gets CS_Get_Account_Data from
> gccGetAccountData.pm, which is "used" in gccDispCustomAcctData.pm and
> is properly exported.

All very well, but the error is telling you that the subroutine
CS_Get_Account_Data isn't defined in package gccDispCustomAcctData at
runtime, which means that it isn't being imported properly regardless of
whether it is exported properly.

You say that this code works fine on some machines but not others? Is it
possible that there is a difference in the httpd.conf files which is
causing this error? Perhaps there is a <Perl></Perl> block in one which
is not in the other?

Something to try is to prefix the call to CS_Get_Account_Data with an
explicit package name (ie call it as
gccGetAccountData::CS_Get_Account_Data) and see what happens then. Either
it'll work or give you more clues.

HTH
Rich

"Richard Gration" <> wrote in message
news:cbp4g1$bib$...
> In article <BPOdnSFE5NeYk0LdRVn->, "Dan Burke"
> <> wrote:
>
> > error_log:[Sun Jun 27 10:25:49 2004] [error] Undefined subroutine
> > &gccDispCustomAcctData::CS_Get_Account_Data called at
> > /opt1/prod/http/cgi-bin/bus/srv_cs_ntt/gccDispCustomAcctData.pm line
> > 182, <DATA> line 225.\n
> > I checked gccDispCustomAcctData.pm, and it gets CS_Get_Account_Data from
> > gccGetAccountData.pm, which is "used" in gccDispCustomAcctData.pm and
> > is properly exported.
>
> All very well, but the error is telling you that the subroutine
> CS_Get_Account_Data isn't defined in package gccDispCustomAcctData at
> runtime, which means that it isn't being imported properly regardless of
> whether it is exported properly.

Well, yes of course that's the problem. The issue is, and why?

> You say that this code works fine on some machines but not others? Is it
> possible that there is a difference in the httpd.conf files which is
> causing this error? Perhaps there is a <Perl></Perl> block in one which
> is not in the other?

I was using a direct copy of the entire apache/conf directory, since the
system was the same, just a newer version of the OS was loaded, the IP's and
all that were the same on the system.

> Something to try is to prefix the call to CS_Get_Account_Data with an
> explicit package name (ie call it as
> gccGetAccountData::CS_Get_Account_Data) and see what happens then. Either
> it'll work or give you more clues.

Ahh, there's an idea. I'll give that a try and we'll see what happens.

Dan.

In article <>, "Dan Burke"
<> wrote:


> "Richard Gration" <> wrote in message
<SNIP>
>> All very well, but the error is telling you that the subroutine
>> CS_Get_Account_Data isn't defined in package gccDispCustomAcctData at
>> runtime, which means that it isn't being imported properly regardless
>> of whether it is exported properly.
>
> Well, yes of course that's the problem. The issue is, and why?>

Very sorry, didn't mean to be patronising. Any luck yet?

R

"Richard Gration" <> wrote in message
news:cbrjea$voq$...
> In article <>, "Dan Burke"
> <> wrote:
>
>
> > "Richard Gration" <> wrote in message
> <SNIP>
> >> All very well, but the error is telling you that the subroutine
> >> CS_Get_Account_Data isn't defined in package gccDispCustomAcctData at
> >> runtime, which means that it isn't being imported properly regardless
> >> of whether it is exported properly.
> >
> > Well, yes of course that's the problem. The issue is, and why?>
>
> Very sorry, didn't mean to be patronising. Any luck yet?
>

I tried specifying the package name, and it still didn't work
I double checked that the pm file is used in that file, and I checked that
it is in %INC. But, I tried to call other sub's from that file and it
bombed with the same error. Most odd. I hate being so stumped like this.

Dan.

In article <>, "Dan Burke"
<> wrote:
> I tried specifying the package name, and it still didn't work I
> double checked that the pm file is used in that file, and I checked that
> it is in %INC. But, I tried to call other sub's from that file and it
> bombed with the same error. Most odd. I hate being so stumped like
> this. Dan.
>

Something else I've just thought of: Is the package returning a true
value? ie is there a "1;" line at the end of it? I suspect so cos I've
seen this error reported specifically. If I were you, at this point I'd
try writing a trivial offline script which uses this file, and then try and
get this file running next as a cgi, then under mod_perl. Hopefully this
will narrow down where the error is occurring. One trick I use is to
introduce deliberate errors in certain places just to make sure that what
I think is happening is actually happening.

HTH
Rich

"Richard Gration" <> wrote in message
news:cc3c4t$1oi$...
> In article <>, "Dan Burke"
> <> wrote:
> > I tried specifying the package name, and it still didn't work I


> Something else I've just thought of: Is the package returning a true
> value? ie is there a "1;" line at the end of it? I suspect so cos I've
> seen this error reported specifically. If I were you, at this point I'd
> try writing a trivial offline script which uses this file, and then try
and
> get this file running next as a cgi, then under mod_perl. Hopefully this
> will narrow down where the error is occurring. One trick I use is to
> introduce deliberate errors in certain places just to make sure that what
> I think is happening is actually happening.
>

Yeah, and I've seen the missing 1; cause errors at compile time. It kinda
seems to be a mod_perl /perl 5.8 thing though, because running the entire
applicaiton outside mod_perl gives no errors. By design this application
was originally made not to use mod_perl, then some 3 years ago we spent
months making it mod_perl safe (it's huge). For the last two years or so
it's been running in mod_perl 1.27, and perl 5.6.1. We decided it was time
to update a bit, perticularly because one environment in Europe required the
better unicode support in perl 5.8. I'm open to any whacked out ideas at
all at this point; this looks pretty grim

Dan.