http://www.perlmonks.org?node_id=813167

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

I get a crash in perl with the following stack trace:

#10 0x5555a3ba in mspace_free ()
#11 0x5555c628 in free ()
#12 0x087bfd48 in Perl_sv_clear ()
#13 0x087d2a06 in do_clean_all ()
#14 0x087ba0fc in Perl_sv_clean_all ()
#15 0x0874b198 in perl_destruct ()

The perl_destruct is called explicitly by my software, to release all memory used by perl.
I think it is related to some bug in my perl script or some wrong coding style.
The perl scripts are big (several thousand lines), so it is not possible for me to find that point easily.
Please tell if you have encountered similar problems or possible reasons.
Perl Version -> perl, v5.8.3 built for i686-linux-thread-multi
Platform -> Linux 32bit
Environment -> perl_module, called from C/C++, and perl_destruct also called from C.

The issue is reproducible only on a testcase, not available at our end.<\br> So can not take the approach of shortening the script and re-running the test-case again.


Thanks

Replies are listed 'Best First'.
Re: Crash in perl_destruct
by Corion (Patriarch) on Dec 17, 2009 at 13:59 UTC

    The only approach I can recommend is reducing the size of your script until the error goes away, and then taking things in again until it appears again, thus finding the module that causes this. An XS module is a very likely cause for this.

    Before we can be of any assistance, we'll need at least the version of Perl you're using, the platform you're using it on, and also the environment you're using Perl in, that is, embedded, mod_perl, or Perl standalone.

      Of course the real WTF is him having a script with several thousand lines of code. =)


      holli

      You can lead your users to water, but alas, you cannot drown them.
      Perl Version -> perl, v5.8.3 built for i686-linux-thread-multi <\br> Platform -> Linux 32bit<\br> Environment -> perl_module, called from C/C++, and perl_destruct also called from C.<\br> <\br> The issue is reproducible only on a testcase, not available at our end.<\br> So can not take the approach of shortening the script and re-running the test-case again.<\br> <\br> <\br> Thanks<\br>