Hello, Dmitry !
Sunday, November 03, 2002, 3:53:16 PM, you wrote:
>> Well the problem is that i'm having an AE at memory_pool.cpp/1470 at :
>> MemoryPool* FBMemoryPool::blk_pool(const void* mem)
>> FullHeader block;
>> read_header(mem, &block);
>> return block.segment->pool->pimplParent;
>> pool member has an invalid value hence AE at the return line, but it's
>> not null or 0xcccccccc , that is it's not unitiliazed nor
>> nulled, it's a weird value ..
> I see the same thing.
>> the block says that it got allocated in jrd\block_cache.h/40..
>> The AE reach a catch block and the lock it's not relased,
>> later raises a
>> deadlock when trying to modify the procedure to set the owner
>> in one of the last gbak phases..
>> Dmitry you were right is a memory problem ;))
> I was telling you this during a month ;-)
>> Well, Any advice on how to deal from that point onward?, it
>> took for me
>> 1'5 months to reach this point any help in be quickest for the next
>> step, well be greatly appreciated :)),
> We've got a memory corruption somewhere. I've traced this memory block from
> it's allocation to SEGV, but haven't found any obvious memory errors. I'd
> suggest John B. to play with new memory manager (after all, it's his child
> ;-) under debugger, but he's away for a couple of weeks. I suspect that the
> problem lies inside the memory deallocation code, although I may be wrong.
> At least I'd start investigating the details of memory segments allocation
> and layout.
Such problems are relatively easy to trace. Just activate hardware write
breakpoint (possibly with some conditions if it happens very often) at
this block just after its allocation and monitor what code modifies it.
This should give you the solution istantly.
Sorry that i can't help you with this issue now because I'm busy
fixing savepoint code now and Rostov work conditions are really not
perfect for Firebird development.
Nickolay Samofatov mailto:skidder@...