Hi,
I googled this whilst searching for a solution to my own XML::Twig
problems - and the probable cause of the error seen by user is an
interesting one to note I think.
XML::Twig uses Scalar::Util::weaken and consumes stack during parsed
structure destruction.
On MS Windows the stack reserve is set when linking your executable.
Up to and including Perl 5.12, when Perl is compiled using MS Visual C,
(as perl ActivePerl) win32/Makefile contains settings to pass a huge
stack size of 16mb.
When compiling PAR::Packer with Visual C the default stack size of 1mb
is used. (default for MinGW is 2mb)
So, if XML::Twig is used to parse an entire file at once, you will run
out of stack a lot quicker in a PAR::Packer executable.
The fix for XML::Twig users is to parse as the module author suggests -
chunk by chunk.
According to the commit that drops the 16mb setting for Perl 5.14, it
was there to cope with some recursive feature of the regex engine but
has not been needed since Perl 5.10 was released. MinGW compiled Perls
(e.g. Strawberry) have never had this increased stack limit.
XML::Twig apart, it seemed worth noting that stack overflow errors in
PAR::Packer on Windows may actually just be code that consumes the stack
but happens not to use 16 mb of it in the user's tests.
The original test error
t/20-pp.t ................ 31
is an issue with the handling of --gui and --icon options to pp - which
always fails with VC built executables. It produces a mangled exec with
a large chunk of rubbish appended which fails in unpleasant ways. MinGW
execs are also mangled - but for some reason the boundary in the gcc
exec where the rubbish begins does not seem to matter - it is on my list
to fix. I had wanted to fix the whole Win32::Exe , application manifest
permission issues - but some of the problems are in PAR::Packer itself
and I haven't got around to testing even basic fixes yet.
Anyway, hope the stack info helps.
Mark
On 07/01/2011 10:48, Roderich Schupp wrote:
On Mon, Jan 3, 2011 at 7:20 PM, Ani Taggu<anita...@gmail.com> wrote:
(b) For the bug.xml file mentioned in the earlier post, everything
works correctly if I do this:
perl myapp.pl<------- OK no problem.
However, if I do
pp -o a.exe myapp.pl
.\a.exe
the crash mentioned above occurs for the sample XML file.
Sorry, I can't reproduce this here, but I don't have exactly the
same setup as you (at least Windows XP vs Vista).
As your experiments show the most likely cause is the custom
perl interpreter used by the packed executable or the few
"essential" modules that it uses during bootstrap. Did you
build PAR::Packer yourself or installed it vis ppm?
If the latter: can you try to build PAR::Packer from source
(including running "dmake test"), install it, then re-pack bug2.pl
and try the resulting executable?
Cheers, Roderich
