Rafal,
I will try and give you all the information I can discern.
After running this several times I discovered it doesn't always crash in the
same place in the test -- just the code. I agree that there is something
funny going on.
So I implemented the "when all else fails on Windows, rebuild from scratch."
Which improved the problems as it manages to execute correctly most of the
time, but still crashes in the same manner once in a while.
Very strange. I am sorry, I cannot explain this behavior. I will try and
work on it a bit more next week.
I will not hold up the review for this. If we find that PB finds the
problems we can go back and look at it. Do you agree?
Chuck
> > The crashes are back on Windows. The problem is now on line#339 in
> > kernel.cc.
>
> This looks very mysterious. The line#399 in kernel.cc is
>
> Backup_restore_ctx::~Backup_restore_ctx()
> {
> close();
>
> delete m_catalog; <-- HERE
> delete m_stream;
> }
>
> in my tree. Is it the same line? Are you sure the exception
> is caught exactly here or somewhere deeper in the call stack
> (for example in the destructor of Backup_info or
> Restore_info)? Is it possible to see the call stack at the crash time?
>
> The only reason I can think about, why "delete m_catalog"
> would generate an exception, is that m_catalog points at
> invalid memory. This could happen either if m_catalog is
> uninitialized (a "dangling pointer") or it was deleted before.
>
> The only place where m_catalog is deleted is the
> Backup_restore_ctx destructor.
> The destructor can't be called twice for the same object
> unless it is called explicitly by "delete". But context
> object instance is not dynamic - it is local variable of
> execute_backup_command() function and is never deleted
> explicitly. Thus the second option is excluded.
>
> The first option also seems out of question. The m_catalog
> member is initialized to NULL inside Backup_restore_ctx
> constructor. It is assigned value only in two places in the
> code: in Backup_restore_ctx::prepare_for_backup() at line#514
> of kernel.cc and in Backup_restore_ctx::prepare_for_backup()
> at line#590. In both cases the value is a valid pointer to
> the newly created Backup_info or Restore_info instance.
>
> Finally, the memory dump you attach:
>
> > - m_catalog 0x01e88aa8 {data_size=30
> m_snap=0x01e8a70c
> > m_table_count=1 ...} backup::Image_info *
> > + st_bstream_image_header {version=1 server_version={...}
> > flags=0 ...} st_bstream_image_header
> > + __vfptr 0x00ca28f8 const
> backup::Image_info::`vftable' *
> > data_size 30 unsigned int
> > + m_snap 0x01e8a70c backup::Snapshot_info * [256]
> > m_table_count 1 unsigned int
> > + mem_root {free=0x01e918d8 used=0x00000000
> > pre_alloc=0x00000000 ...} st_mem_root
> > + m_dbs {...} Map<unsigned int,backup::Image_info::Db>
>
> indicates that m_catalog points at a valid object instance,
> not at some random bytes.
>
>
> All this makes me think that the problem is not exactly at
> "delete m_catalog"
> line but must lie somewhere deeper. I need more info to find
> out where.
