I have a module that is a xs interface to the Aspell/Pspell library. The
library is written in c++. The module is Text::Pspell on CPAN.
It works perfectly on my SuSE/perl 5.6.0 machine.
It works perfectly on Solaris 2.6 perl 5.005_03
On my Debian woody with perl 5.6.1 it gives a sig abort if run with
PERL_DL_NONLAZY=1 but works fine when PERL_DL_NONLAZY=0 (red herring is my
guess).
On FreeBSD 4.5 with 5.005_03 it always aborts (regardless of PERL_DL_NONLAZY).
If I copy the .xs code into a main {} block and build a stand-alone C
program it works fine everyplace.
My efforts with gdb have not been very successful.
What seems to be happening is that the aspell c++ code attempts to open
configuration files, and when a file is not found it aborts. These config
files are *optional* and don't exist on any of my platforms. On the debian
system, where it only aborts with PERL_DL_NONLAZY=1 (which is set with
"make test"), if I touch all the config files then make test then runs
without problem.
The aspell c++ code throws an exception when a config file doesn't exist.
But the code that reads the config file is wrapped in a try / catch block,
and the catch block just ignores the error (empty block).
I edited the aspell source code to print a message as the last line of the
exception constructor, and also in the catch block. The idea is the
exception is thrown, the constructor is called, and then the catch block
should be executed. (Note: I'm not a c++ programmer..)
So with PERL_DL_NONLAZY=0 I see the message from the constructor, and then
from the catch block. But with PERL_DL_NONLAZY=1 I see the constructor
message and then the program aborts without displaying the line from the
catch block.
I don't know c++. From what I understand what happens between the
exception constructor and the catch block is that any nested objects are
destroyed. So perhaps there's another exception or abort() called in one
of those.
But to me it seems more like a problem with Perl since all I'm changing is
PERL_DL_NONLAZY. I have not been able to see anything with gdb single
stepping through the code after the exception is called, but that could be
my poor debugging skills.
I don't think it's really an issue with what PERL_DL_NONLAZY does, as it's
hard to imagine why perl's behavior with dlopen() would have anything to do
with what's happening in the c++ shared library. But that's just a guess.
Anyway, it's obvious that I'm stuck. Any suggestions?
Thanks,
--
Bill Moseley
mailto:[EMAIL PROTECTED]
