I notice that building with Perl 5.6.1 (on Win32 with Perl 5.6.1 ActiveState-build 635 and MinGW) causes problem.$ parrot Assertion failed: (int)io->image->bufused >= 0, file src/pmc_freeze.c, line 478 abnormal program termination This assertion occurs in parrot_get_config_string(). The data parrot_config[] (file src/parrot_config.c) is not valid. This data is the frozen version of runtime/parrot/include/config.fpmc runtime/parrot/include/config.fpmc is a transformation of config_lib.pasm And I don't found a real explanation ...
On windows, run-time libraries supplied with compilers distinguish between files open in the text and binary mode and the perl 5.6.* default open mode for plain files is text (this is not true as of perl 5.8.*, correct me if I am wrong). So after the following lines are executed
$_ = <F>; my @c = split '';@c ends up containing only 208 chars, though config.pmc is of 11588 chars. I can't talk about implementation of fread in all the windows compillers, but MS VC's one does as follows: first it slurps the whole file in the buffer, then it checks if is running in the text mode, and if so, moves the pointer to the begin of the buffer and starts scanning it for CR-LF and CTRL-Z. If fread encounters CR-LF, it maps CR-LF to LF, if encounters CTRL-Z it stops the scanning and assigns the position, where CTRL-Z is found at, to the number of bytes read.
In this particular case, fread gets CTRL-Z at 209 position, so the script parrot_config_c.pl produces incomplete frozen pmc representation which is of 208 chars only, and that's why assertion fails when thaw_pmc tries to thaw it.
The patch applied fixes the problem at least on my PC which runs perl 5.6.2
parrot_config_c.pl.patch
Description: Binary data
