B::C now dumps core often
Konovalov, Vadim (Vadim)** CTR **
right now, B::C is not able to correctly deal with compiling large modules,
and I start digging into the problem.
for example, compiling BigInt.pm into pmc creates this pmc seemingly
correctly, but then it leads to crash during loading of the module.
Reproducible on windows and linux at least.
I seemingly found one of examples of such dump core.
Let us say bigint case.
It fails here -
(an excerpt from byterun.c)
case INSN_OP_NEXT: /* 94 */
{
opindex arg;
BGET_opindex(arg);
DEBUG_v(Perl_deb(aTHX_ "(insn %3d) op_next opindex:0x%lx, ix:%d\n", insn, PTR2UV(arg), (int)ix));
PL_op->op_next = arg;
DEBUG_v(Perl_deb(aTHX_ " PL_op->op_next = 0x%lx;\n", PTR2UV(arg)));
break;
}
It runs hundreds times through this portion of C code but then fails.
Looking into BigInt.pmc file in hex, reveals at this place:
5E 0D 0A 00 00 74 .....
and dissassembled pmc file is
op_next 1946157066
5E is the code of operation "op_next", and number 1946157066 is this "0A 00 00 74" (7400000A)
Actually I am pretty sure that it should be "op_next 2573" and then "74" opcode.
(because in disassembled pmc I see "op_next 2572" and "op_next 2571" etc in few lines above)
Could it be that "0D" got eaten due to these source filters new behaviour?
Regards,
Vadim.
Reini Urban
<vadim.k...@alcatel-lucent.com>:
Oh my. Sure. I forgot to fix ByteLoader for 5.14
Is it 5.14 or earlier?
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Konovalov, Vadim (Vadim)** CTR **
> 2011/5/14 Konovalov, Vadim
> > Could it be that "0D" got eaten due to these source filters new behaviour?
>
> Oh my. Sure. I forgot to fix ByteLoader for 5.14
> Is it 5.14 or earlier?
This was 5.13.11,
and I haven't tried other perls,
well, I tried 5.12.1 but then I quickly realized that it lacks this
"store_cop_label" on Win32, which makes B::C useless there...
thanks for looking into the problem.
Vadim.
Reini Urban
>
>> 2011/5/14 Konovalov, Vadim
>
>> > Could it be that "0D" got eaten due to these source filters new behaviour?
>>
>> Oh my. Sure. I forgot to fix ByteLoader for 5.14
>> Is it 5.14 or earlier?
>
> This was 5.13.11,
Can you try this patch please?
Works for me, but it is not easy to create a testcase which has \r\n
in the binary stream.
--- ByteLoader/ByteLoader.xs (revision 1026)
+++ ByteLoader/ByteLoader.xs (working copy)
@@ -94,6 +94,11 @@
data.next_out = 0;
data.datasv = FILTER_DATA(idx);
+ /* [perl #86186] Using tell(DATA) within __DATA__ file buffer is
broken on Win32:
+ Source filters were changed with 5.14 to read DATA in
textmode, so \r\n are
+ changed to \n in our binary data.
+ */
+ PerlIO_binmode(aTHX_ PL_RSFP, IoTYPE_RDONLY, O_BINARY, 0);
data.idx = idx;
bstate.bs_fdata = &data;
Konovalov, Vadim (Vadim)** CTR **
> Can you try this patch please?
> Works for me, but it is not easy to create a testcase which has \r\n
> in the binary stream.
>
> --- ByteLoader/ByteLoader.xs (revision 1026)
> +++ ByteLoader/ByteLoader.xs (working copy)
> @@ -94,6 +94,11 @@
>
> data.next_out = 0;
> data.datasv = FILTER_DATA(idx);
> + /* [perl #86186] Using tell(DATA) within __DATA__ file buffer is
> broken on Win32:
> + Source filters were changed with 5.14 to read DATA in
> textmode, so \r\n are
> + changed to \n in our binary data.
> + */
> + PerlIO_binmode(aTHX_ PL_RSFP, IoTYPE_RDONLY, O_BINARY, 0);
> data.idx = idx;
>
> bstate.bs_fdata = &data;
nothing changed for me, unfortunately.
also I could say that the problem exactly the same on windows and linux, so it could be
something different than just win32 DATA.
If you're lucky with, say, BigInt.pmc - can you plesease send it to me, so I could compare the files?
Regards,
Vadim.