Debugger problem in 5.10

[duoxi]

Hope you had a great New Year!

I have been working on a perl application for a number of years, most recently under perl 5.8 Yesterday I installed a new Ubuntu system on my laptop which came with perl 5.10.

Now I experience that the debugger core dumps when it invokes Storable. When the application is run without the debugger (this is a CGI script) everything works fine, but in effect, working under the debugger is now impossible.

The debugger also core dumps in other situations, such as when it is trying to write a file that is write protected (which did not cause this error before).

I wonder if anybody could point me to how to solve or work around this problem. Do you experience the same problem with debugging under perl 5.10? Or could the problem be with the ubuntu installation?

Any guidance is greatly appreciated.

Cheers, D.

[borisz]

I guess you thaw/retrieve data that was freezed/storedwith another perl or another architecture. Just remove all old data that was serialized with the other computer and use the portable nfreeze/nstore instead of freeze/store next time.

[duoxi]

Boris,

thanks. I did think of this and deleted all previously created archives. Also, I am not using freeze/thaw. I am using the following calls:

Storable::lock_store
Storable::lock_retrieve

Again, the code works fine when run in normal mode. But when I get to lock_store in the debugger, it core dumps (actually, somewhere inside the Storable routine)...

[borisz]

Then use lock_nstore and do not rely on any data stored another way, ported to your new computer. Not in a config file not via a database ,... and so on.

[tye]

It is possible that Storable was installed such that the 5.8 version of the compiled part of the code was attempted to be used by the 5.10 version of Perl? Nah, that seems unlikely to happen and unlikely to be the cause of your complaint.

In trying to reproduce your problem, I did notice a bug in the 5.10 debugger. The handling of "constant" subroutines appears to have changed in 5.10 and they now cause the code that looks for subroutine names to die:

 > perl5.10 -del

Loading DB routines from perl5db.pl version 1.3

  DB<1> o die=0
  DB<2> use Storable
  DB<3> m Storable
Not a subroutine reference at /usr/lib/perl5/5.10/perl5db.pl line 7934
+.
Debugged program terminated.  ...

But I was unable to reproduce any of the problems you complained of (but this was on cygwin -- not having a 5.10+Ubuntu combination handy).

The standard route when you run into core dumps is to upgrade or downgrade the item that is core dumping. In this case, I would probably build and install my own copy of Perl from source (since it is standard wisdom to let Linux have whatever version of Perl it wants and to give yourself a separate version of Perl that you can mess with without surprising the parts of Linux that expected the shipped-with Perl to be there).

[duoxi]

I believe I traced the problem down to line 380 in my version of Storable.pm (2.18):

    eval { $self = pretrieve(*FILE) };

which based on the comments in the file is a call to a C routine.

I found other issues, such as that the taint checking does not always seem to work correctly, and variables are considered tainted under the debugger even when they are properly untainted (and they are not considered tainted when the code is run without the debugger).

[tye]

That would make me more interested in installing my own copy of Perl (from source) and using that.

I would probably also try a bit to see if I could resolve the problem with the system's Perl (since these seem serious enough that the system might run into problems when it goes to use this flakey install of Perl). Perhaps forcing a re-install as a first step.

[andreas1234567]

It would probably be helpful if you posted some relevant code.

[trwww]

Hello,

Obviously perl 5.10 is a version of perl 5, but from my research, personally I wouldn't expect a 5.8 application of any substance to work unmodified on perl 5.10.

What I do in your situation is install perl 5.8 in an isolated location (perhaps /home/me/myapp/extern) and then set up an environment with that perl (/home/me/myapp/extern/bin) in the $PATH just for that app.

Regards,

[ysth]

I wouldn't expect a 5.8 application of any substance to work unmodified on perl 5.10.

I would. Looking through http://perldoc.perl.org/perldelta.html#Incompatible-Changes, there are a number of previously deprecated things removed and a number of changes that are basically bug fixes (where the new behavior is less surprising than the old), and very little else (depending on how much you personally place in the second category).