jdtoronto has asked for the wisdom of the Perl Monks concerning the following question:

Esteemed Monks,

I am about ready to do something desperate! Thelast few days I have been adding major requested features to a Win32 app - which is now using Class::DBI. I have use C::DBI quite successfully on some web projects and so I blithely went ahead and wrote it this way.

To localise the problem I have cut the code into little bits and put it back together to the point where it stops working. And when I mean stops - PerlApp exits unceremoniously.

package InContact::cDBI; use strict; use Data::Dumper; use Class::DBI; use Class::DBI::mysql; use base 'Class::DBI::mysql'; InContact::cDBI->set_db('Main', 'dbi:mysql:incontact', 'root', ''); package InContact::cDBI::contactdetail; use base 'InContact::cDBI'; #__PACKAGE__->set_up_table('contactdetail'); #__PACKAGE__->has_a('contact_id' => 'InContact::cDBI::contact'); package InContact::cDBI::contact; use base 'InContact::cDBI'; # #__PACKAGE__->set_up_table('contact'); #__PACKAGE__->has_many('contact_detail' => 'InContact::cDBI::contactde +tail', 'contact_id'); # 1;
If I un-comment any of the commented lines then PerlApp will crash with the following error reported on the command line:
Free to wrong pool 88b278 not c0104 during global destruction. 'start4_01.pl' had compilation errors.

To me this smells of a threading issue, but I am not knowledgable enough to be able to go any further. Any clues? I have tried PDK5.3.0 and 5.2.0, ActivceState Perl 5.8.4 and 5.8.3.

jdtoronto

Replies are listed 'Best First'.
Re: PerlApp and Class::DBI don't mix! or do they?
by perrin (Chancellor) on Oct 06, 2004 at 04:07 UTC
    I don't know much about PerlApp, but my interpretation is that the "Free to wrong pool" bit is just a message being generated during shutdown after the real error has caused things to stop. Are you sure there's no other error message? "Had compilation issues" is not a very useful message.

    Class::DBI is pure Perl and makes no use of threads, so I don't suspect a threading issue. Maybe you're just missing a required module?

Re: PerlApp and Class::DBI don't mix! or do they?
by dragonchild (Archbishop) on Oct 06, 2004 at 13:18 UTC
    To me this smells of a threading issue, ...

    Are you using a threaded Perl? Are you sure you have the MySQL table set up properly? Do you have the proper DBD::mysql installed? What version of MySQL are you running? Imho, it seems very odd that you would run into this problem only when actually doing database work.

    I would try the following as a test:

    #!/usr/bin/perl use strict; use warnings; use DBI; my $dbh = DBI->connect( 'Main', 'dbi:mysql:incontact', 'root', '', { R +aiseError => 1 } ) or die $DBI::errstr; print "Have DBH!\n"; my $sth = $dbh->prepare( 'SELECT 1' ); $sth->execute; my @x = $sth->fetchrow_array; print "@x\n"; $dbh->disconnect; print "Done\n";

    If, as I suspect, that script fails, the problem is not with Class::DBI or threading or anything fancy - it has to do with your database and how you're connecting to it. If that script succeeds, then you do have a zebra.

    Remember - most interns in teaching hospitals think that every cough is a sign of Ebola when, 99.999999% of the time, it's just a cough.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      Are you using a threaded Perl?

      Active State's distribution is always threaded.

      Are you sure you have the MySQL table set up properly? Do you have the proper DBD::mysql installed?

      The application has been in the works for over 12 months and the database has been working fine. About two weeks ago I did a release that used all hard coded or SQL::Abstract based SQL. It packaged nicely with PerlApp and built nicely into a setup.exe package using NSIS which delivers the database, installs it, and puts around 4.5 million records in the database.

      My sin was to change what I was doing! I had a request for a major new feature addition. So I started a new module and I decided to use Class::DBI to get the flexibility with reduced coding time. From teh command line it works beautifully, but after compiling it with PerlApp - nix!

      It seems that the thread issue is a red herring. By adding the --nocheck option to the PerlAppinvocation you can avoid the crash. The real issue seems to be module dependencies. Slowly - bit by bit, I am going through and adding use statements for the modules used by other modules. Each time things get a little better! It seems the real problem is that PerlApp is unable to find modules required by other modules!

      Thanks for the suggestion, and for the opportunity to vent a little :)

      jdtoronto

Re: PerlApp and Class::DBI don't mix! or do they?
by CountZero (Bishop) on Oct 06, 2004 at 18:56 UTC
    I think it is a DBI-issue. have a look here. Switching to DBI 1.45 might solve it.

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      Thank you!

      My DBI is a fwe days old - must be time for an update!

      jdtoronto