On 2002.11.23, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Using my encoding-aware nscp:
[...]
> $m is the same as $u
Very cool! Is there a reason why we wouldn't want your changes to
nscp checked into CVS?
> > Any idea what I'm doing wrong?
>
> As already posted to the list: the nscp trashes encoding.
Right. It appears the ADP processor does, too. Matter of fact,
it sounds like a lot of places might be doing it ... (I suspect
the DB interface also does it, but I haven't checked.)
> But, the initial question was about the memory corruption
> wasn't it? Somehow you got complaints from the memory
> allocator which I'm not able to reproduce. Now, what was
> the corrective measure again? It did have to do something
> with nsv_* arrays, did it?
The initial error I was reported was:
alloc: invalid block: ff2bb898: ff 70 0
alloc: invalid block: ff2bb898: ff 70 0
There were probably 200,000 nsv arrays created, using about 300 MB
of memory. I'm only guessing at these numbers -- I didn't have the
opportunity to take actual counts before the thing croaked.
After modifying my application to periodically nsv_unset when they are
no longer needed, the error has gone away and the server hasn't crashed
since. I might have just been hitting some limit somewhere with the
number of nsv's ...
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
