On Mon, 19 Oct 2009, Alex Strickland wrote:
Hi,
> I have been working with ActiveX again. If I comment out the call to
> Release() in hb_ole_destructor() in olecore.c the GPF does not
> occur.
> That is not very helpful so I wondered if Release() depends in some
> way on whether OleUninitialize() has been called. If I restore the
> call to Release() and I comment out OleUninitialize() the GPF also
> goes away.
Harbour executes OleUninitialize() as HVM atQuit function after releasing
all Harbour items so when this function is called no other OLE code can
be activated by Harbour.
> I guess the order of calls on shutdown is not deterministic and
It is. See hb_vmQuit() which executes hb_vmDoModuleQuitFunctions().
> calls to Release after OleUnitialize() appear to cause a GPF. This
It cannot appear from Harbour code.
> is some debug output where OleUnitialize() is not actually called
> (commented):
>
> [5240] OleInitialize
> [5240] OleUninitialize
> [5240] hb_ole_destructor
> [5240] after hb_ole_destructor
> [5240] hb_ole_destructor
> [5240] after hb_ole_destructor
>
> If I restore the call to OleUnitialize():
>
> [4792] OleInitialize
> [4792] OleUninitialize
> [4792] hb_ole_destructor
> GPFs here
The above code activates hb_ole_destructor after releasing HVM and
it's done by some code which is not part of Harbour core code. I.e.
some 3-rd party code does not use autodestructors for allocated
system objects and keep references to internal Harbour structures
after releasing HVM. I.e. some windows are still active and default
window loop code calls HVM functions.
In such case even if you comment OleUnitialize() then it does not
fix anything because program is still buggy and can still GPF after
accessing release HVM structures.
It's also possible that the problem is caused by multiple calls to
OleUninitialize(). This is Mindaugas note from contrib/hbwin/oleinit.c:
/*
* Duplicated OleUninitialize() call causes GPF. So, if a few OLE libraries
* is used inside Harbour code, you can expect GPF on application exit.
* This code does not implement any OLE interface except initialization. It is
* have to be used from all other OLE libraries. [Mindaugas]
*/
So if you are using some 3-rd party code then you should check if it does
not call OleUninitialize(). I.e. in HWGUI you should modify htmlfunc.c in
source/activex:
#include "hbwinole.h"
HB_FUNC( HWGAX_OLEINITIALIZE )
{
hb_oleInit();
hb_retl( TRUE ); // I'll change hb_oleInit() to return TRUE/FALSE in
// in a while
}
HB_FUNC( HWGAX_OLEUNINITIALIZE )
{
/* it's called automatically by HVM */
}
Please check if it's not the reason of your problems.
> I hope this analysis is correct. I could not find information on
> whether it is supposed to be allowable to call Release() after
> OleUnitialize().
I think it's illegal but if the problem is caused by some 3-rd party
code which does not release allocated system resources before HVM quit
and this code can activate some HVM core code after releasing HVM
structures then I'm afraid non of us will be able to help you.
In general it would greatly help if you can create self contain example
using only Harbour SVN code which we can compile and verify the problem.
If this is Harbour problem then it should be possible to create such
examples and in such case we should be able to fix it quite easy.
BTW have you tried you tried to recompile Harbour core code with
set HB_USER_CFLAGS=-DHB_FM_STATISTICS
?
It should help to catch code which does not free some resources or
free them more then once.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
