On Sat, Jul 07, 2012 at 12:11:12PM +0400, "Dmitry E. Oboukhov"
<un...@debian.org> wrote:
> 1000 +- 100 hashes with 3-4 fields in 100 asyncs...
> test computer has more than 4G RAM.
Good luck having those 4G of ram allocated to your stack - memory
management doesn't work like you think it does.
> > You can verify that by using gdb to get a backtrace on the crash - most
> > likely you will see hundreds of recursions inside sv_free.
>
> by default ulimit -s == 8192, Coro::State::cctx_stacksize == 16384
>
> I've increased these limits upto 3276800000 - the script segfaults.
These allocations probably fail - use sensible values please, and keep in
mind you need to set the stackspace before stacks are being created.
> But If I comment 'weaken' lines (and head pointer in $head variable)
> it doesn't crash even if ulimit -s == 8192 /
> Coro::State::cctx_stacksize == 16384.
Of course, stack size requirements are a lot smaller in that case.
> and the code that crashes have the same stack requirements.
Of course not - please don't make up statements as you go without
verifying them.
> So I think that crashes happen if You use 'weaken' in Yur objects.
Yes, thats true, but that has nothing to do with Coro, you are running out
of stack space. Weaken changes your allocation pattern considerably.
If you had made a backtrace and investigated it you would see that your
theory doesn't hold any water. As long as you ignore reality and insist on
some fantasy theory you will not make progress.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
