Is %msg a tied hash of some kind? Where did it come from? If it's a tied hash, you'd have to look at how the tied class implements DELETE...
--
Mike

ain't got no password to login still, sorry ;) well, this exerpt of code isn't supposed to segfault, it is perfectly valid, but it did a certain number of times .... ( according to sigtrap ). The hash was a perfectly normal hash, no tying or whatsoever. What about XML::Parser ? Is it likely to segfault ?

here is a portion of the stacktrace

Caught a SIGSEGV at /usr/lib/perl5/site_perl/5.6.1/i386-linux/XML/Pars
+er/Expat.pm line 469
$ = XML::Parser::Expat::parse('XML::Parser::Expat=HASH(0x81cc7bc)', *Q
+MM_MOD::emi::DATA) called from file `/usr/lib/perl5/site_perl/5.6.1/i
+386-linux/XML/Parser.pm' line 185
$ = eval {...} called from file `/usr/lib/perl5/site_perl/5.6.1/i386-l
+inux/XML/Parser.pm' line 184
$ = XML::Parser::parse('XML::Parser=HASH(0x4040b97c)', *QMM_MOD::emi::
+DATA) called from file `/usr/lib/perl5/site_perl/5.6.1/i386-linux/QMM
+_MOD/emi.pm' line 33
[download]

It's not clear why XML::Parser is segfaulting if no calls are being made to it by that code. Segfaults usually indicate serious problems with external libraries, and aren't usually thrown by (stable) versions of perl unless it invokes them. I'm afraid diagnosis of this problem requires looking at more than just the code.

One possiblity that pops to my mind is that your version of XML::Parser was compiled with a particular version of the expat C libraries, and that the version of expat installed on your system is a different one.

HTH

If not P, what? Q maybe?
"Sidney Morgenbesser"