Hi Jandrew :)
1) I see StrawberryPerl64, have you tried with StrawberryPerl 32 bits?
I say this because I installed version 32 bits on Windows Server 2012 64 bits for threads problem or stability.
2) Did you profile your code?
(if there is memory leaks, over usage of RAM...).
With Devel::NYTProf in console:
https://metacpan.org/pod/Devel::NYTProf
perl -d:nytprof foo.pl<br>
./nytprofhmtl --open #to generate the html output and open the index f
+ile)
Peace | [reply]
[d/l] |
hotchiwawa Thank you for your suggestions. At this point I would rather try and get StrawberryPerl64 to work or at least get some kind of coherent/small failing test case rather than/before I use a 32 bit StrawberryPerl From a general memory standpoint I am not really budging the needle (~72M of RAM before dying) but I'm doing my checking in the task manager so there may or may not be a different result in perl. However based on my research this error code can occur (among other reasons) in windows when an attempt to access a memory location is made after the contents have been deleted. Currently I'm following up on fishmongers suggestions as well as looking into Devel::cst and Devel::SizeMe.
Update: it looks like Devel::cst and Devel::SizeMe are both Linux specific modules requiring execinfo.h Devel::cst in this case seemed very promising.
| [reply] |
Yep, good point with Devel::SizeMe and Devel::cst, thanks, I searched this kind of modules too :)
Maybe you can also use autodie, to quit the application maybe before your current issue and get a possible source of the error...
Edit: check Devel::Size, seems to have the same methods that Devel::SizeMe, but release in 2015 with less dependencies.
| [reply] |
fishmonger++ perl -d:Trace 01-libxml.t errored out after the line from the primary module
$self->_DESTROY which I believe is a Moose addon. This seems like the biggest smoking gun. I got no joy from Devel::Dumptrace. The first time I ran it in verbose mode it overran the memory on my 16G Ram machine. The second time I ran it in quiet mode and I couldn't tell if it locked up or was just grinding away with no output but after about a half an hour I quit.
Based on the last executed line from Devl::Trace as $self->_DESTROY I'm suspecting some trickiness that I tried where two instances are holding an attribute with a reference to each other. In fairness the simple case of this doesn't fail but I suspect that there probably is a really large "don't go there!" sign somewhere in the Moose documentation that I missed. I think I have some possible workarounds to try but I have reached the limit of root causing this based on available tools from the Monastery so I'm headed back to the architecture drawing board to poke at alternatives. It would have been nice if the tricky cross referencing had worked though.
| [reply]
[d/l] |
| [reply] |
