undefined subroutine that is defined? mob_perl / perl 5.8.4 issue?

Discussion in 'Perl Misc' started by Dan Burke, Jun 27, 2004.

  1. Dan Burke

    Dan Burke Guest

    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
     
    Dan Burke, Jun 27, 2004
    #1
    1. Advertising

  2. In article <>, "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, Jun 28, 2004
    #2
    1. Advertising

  3. Dan Burke

    Dan Burke Guest

    "Richard Gration" <> wrote in message
    news:cbp4g1$bib$2surf.net...
    > In article <>, "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.
     
    Dan Burke, Jun 28, 2004
    #3
  4. 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, Jun 29, 2004
    #4
  5. Dan Burke

    Dan Burke Guest

    "Richard Gration" <> wrote in message
    news:cbrjea$voq$2surf.net...
    > 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.
     
    Dan Burke, Jul 1, 2004
    #5
  6. 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, Jul 2, 2004
    #6
  7. Dan Burke

    Dan Burke Guest

    "Richard Gration" <> wrote in message
    news:cc3c4t$1oi$2surf.net...
    > 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.
     
    Dan Burke, Jul 5, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark
    Replies:
    0
    Views:
    509
  2. Oodini
    Replies:
    1
    Views:
    1,845
    Keith Thompson
    Sep 27, 2005
  3. Replies:
    4
    Views:
    200
    Bob Walton
    Aug 12, 2003
  4. Torsten Mangner

    testing for 'undefined subroutine'

    Torsten Mangner, Nov 4, 2003, in forum: Perl Misc
    Replies:
    3
    Views:
    158
    Bob Walton
    Nov 5, 2003
  5. king
    Replies:
    5
    Views:
    210
Loading...

Share This Page