Re: [ID 20000308.007] utf8 interfering where it didn't ought to

I've been having a somewhat frustrating time trying to follow this
effect up.    It seems to be something of a Heisenbug.    This is a
report of where I've got to so far.    If any of this stuff rings any
bells, I'd be glad of advice on how to proceed.

First, here's a simpler related example (under perl5.6.rc1 rather
than 5.5.670):

  DB<1> x "\xff\xff\xff\0"
0\c@"
Malformed UTF-8 character, <IN> line 1.
	dumpvar::unwrap(undef, undef, 'M-^?M-^?M-^?^@', 3) called at /home/mjtg/perl5.6.rc1/lib/dumpvar.pl line 110
	dumpvar::DumpElem('M-^?M-^?M-^?^@', 3) called at /home/mjtg/perl5.6.rc1/lib/dumpvar.pl line 212
	dumpvar::unwrap('ARRAY(0x1b37d4)', 0) called at /home/mjtg/perl5.6.rc1/lib/dumpvar.pl line 33
	main::dumpValue('ARRAY(0x1b37d4)') called at /home/mjtg/perl5.6.rc1/lib/perl5db.pl line 1370
	DB::dumpit('GLOB(0xf7cf8)', 'ARRAY(0x1b37d4)') called at /home/mjtg/perl5.6.rc1/lib/perl5db.pl line 1305
	DB::eval called at /home/mjtg/perl5.6.rc1/lib/perl5db.pl line 1188
	DB::DB called at -e line 1
Can't call method "SWASHGET" without a package or object reference, <IN> line 1.
	dumpvar::unwrap(undef, undef, 'M-^?M-^?M-^?^@', 3) called at /home/mjtg/perl5.6.rc1/lib/dumpvar.pl line 110
	dumpvar::DumpElem('M-^?M-^?M-^?^@', 3) called at /home/mjtg/perl5.6.rc1/lib/dumpvar.pl line 212
	dumpvar::unwrap('ARRAY(0x1b37d4)', 0) called at /home/mjtg/perl5.6.rc1/lib/dumpvar.pl line 33
	main::dumpValue('ARRAY(0x1b37d4)') called at /home/mjtg/perl5.6.rc1/lib/perl5db.pl line 1370
	DB::dumpit('GLOB(0xf7cf8)', 'ARRAY(0x1b37d4)') called at /home/mjtg/perl5.6.rc1/lib/perl5db.pl line 1305
	DB::eval called at /home/mjtg/perl5.6.rc1/lib/perl5db.pl line 1188
	DB::DB called at -e line 1
Debugged program terminated.  Use q to quit or R to restart,
  use O inhibit_exit to avoid stopping after program termination,
  h q, h R or h O to get additional info.  
  DB<2>

Note we get the Malformed message as well as the original "SWASHGET".
Note also that the error messages don't contain file/line information,
but do contain current input info.   (This was also true in the original
example.)

Also the argument lists in the backtrace are somewhat mangled  -  see
the "undef"s in the calls to dumpvar::unwrap.

The above backtrace was produced on Saturday.   I next tried to close
in on the problem by putting print statements in dumpvar.pl, and the
effect promptly went away.    So I took the print statements out
again, but the effect stayed away.   And I haven't been able to
reproduce it since.

I'd originally discovered the bug while running one of my production
jobs under the debugger.    (Because it was generating "Uninitialised"
messages under 5.5.670 which didn't happen with 5.005_03.)    So I
tried running that again.    And the failures reappeared.    But
that's in the middle of a very large program, so extracting a small
example will be difficult.   And the effect will probably go away
as I cut the program down.

Sigh.

Just tried building a clean rc1  -  and the bug shows again!
Back to regularly scheduled debugging ...


Mike Guy

• [ID 20000308.007] utf8 interfering where it didn't ought to by M.J.T. Guy
• Re: [ID 20000308.007] utf8 interfering where it didn't ought to by M.J.T. Guy
• Re: [ID 20000308.007] utf8 interfering where it didn't ought to by M.J.T. Guy
• Re: [ID 20000308.007] utf8 interfering where it didn't ought to by Gurusamy Sarathy
• Re: [ID 20000308.007] utf8 interfering where it didn't ought to by M.J.T. Guy