14.07.2021 15:41, Dimitry Sibiryakov wrote:
In this thread I was trying to find out WHY the order of events is like this
Just to expand the thesis: if it had been found out that the routines are called after
library unload - it would be a serious bug either in the engine or in the plugin.
14.07.2021 15:33, Vlad Khorsun wrote:
For me it is irrelevant because I don't set any logic on this
Hmm... so what we speak about in this thread ?
In this thread I was trying to find out WHY the order of events is like this (I'm quite
ignorant about Linux you know) and whether it is
14.07.2021 16:16, Dimitry Sibiryakov wrote:
14.07.2021 15:08, Vlad Khorsun wrote:
And this is correct. What is not good for you is that it is called not because
of module
unload (by Plugin Manager), AFAIU.
For me it is irrelevant because I don't set any logic on this
Hmm... so what we
On 7/14/21 3:37 PM, Vlad Khorsun wrote:
14.07.2021 15:29, Dimitry Sibiryakov wrote:
14.07.2021 14:25, Vlad Khorsun wrote:
Are you sure fb_shutdown() was called before exit() ?
isql calls fb_shutdown() in atexit() handler so it is surely
called after exit().
Yes, indeed. In isql fb_s
14.07.2021 15:08, Vlad Khorsun wrote:
And this is correct. What is not good for you is that it is called not because
of module
unload (by Plugin Manager), AFAIU.
For me it is irrelevant because I don't set any logic on this but for the engine itself
it may be a problem when it is used from
14.07.2021 15:34, Dimitry Sibiryakov wrote:
And here is a call stack from module destructor which in this case workd as
UnloadDetector:
#1 0x768f4921 in __GI_abort () at abort.c:79
#2 0x70a5ff89 in PluginModule::~PluginModule (this=0x70f971b0 ,
__in_chrg=)
at /hom
14.07.2021 14:37, Vlad Khorsun wrote:
I don't know for sure when globals of loaded modules is destoyed by Linux
loader.
The second stack trace shows that it also happen in onexit handler and they are in the
same list, executed in order reversed to registration.
Fortunately it seems to be
14.07.2021 15:29, Dimitry Sibiryakov wrote:
14.07.2021 14:25, Vlad Khorsun wrote:
Are you sure fb_shutdown() was called before exit() ?
isql calls fb_shutdown() in atexit() handler so it is surely called after
exit().
Yes, indeed. In isql fb_shutdown() is called as part of exit(), to
And here is a call stack from module destructor which in this case workd as
UnloadDetector:
#1 0x768f4921 in __GI_abort () at abort.c:79
#2 0x70a5ff89 in PluginModule::~PluginModule (this=0x70f971b0 ,
__in_chrg=)
at /home/sd/ibptrace/plugin/main.cpp:248
#3 0x7f
14.07.2021 14:25, Vlad Khorsun wrote:
Are you sure fb_shutdown() was called before exit() ?
isql calls fb_shutdown() in atexit() handler so it is surely called after
exit().
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebi
14.07.2021 15:14, Dimitry Sibiryakov wrote:
14.07.2021 13:06, Alex Peshkoff via Firebird-devel wrote:
Looks like it is not thread races or I did call gettid() wrongly.
But if all that chain was called from fb_shutdown() it does not matter - UnloadDetector is not needed. Can you show the stac
14.07.2021 13:06, Alex Peshkoff via Firebird-devel wrote:
Looks like it is not thread races or I did call gettid() wrongly.
But if all that chain was called from fb_shutdown() it does not matter - UnloadDetector is
not needed. Can you show the stack trace when doClean is called?
Here it i
14.07.2021 14:16, Dimitry Sibiryakov пишет:
14.07.2021 13:12, Vlad Khorsun wrote:
Good. In this case the scenario is:
- app call fb_shutdown()
- fb_shutdown() call doClean() of every loaded plugin module and unload dll
module
- windows loader call DllMain of unloading module (actually it is
On 7/14/21 2:13 PM, Dimitry Sibiryakov wrote:
14.07.2021 13:06, Alex Peshkoff via Firebird-devel wrote:
Without a kind of UnloadDetector in your plugin PluginManager is not
aware that your plugin was unloaded on exit().
But if all that chain was called from fb_shutdown() it does not
matter - Un
14.07.2021 13:12, Vlad Khorsun wrote:
Good. In this case the scenario is:
- app call fb_shutdown()
- fb_shutdown() call doClean() of every loaded plugin module and unload dll
module
- windows loader call DllMain of unloading module (actually it is not DllMain
but
some other entrypoint of
14.07.2021 13:06, Alex Peshkoff via Firebird-devel wrote:
Without a kind of UnloadDetector in your plugin PluginManager is not aware that your
plugin was unloaded on exit().
But if all that chain was called from fb_shutdown() it does not matter - UnloadDetector is
not needed. Can you show the st
14.07.2021 13:22, Dimitry Sibiryakov wrote:
14.07.2021 12:13, Vlad Khorsun wrote:
Why do you think it does ? Do you have a stack trace ?
Yes. Functions after global destructors are called from fb_shutdown().
Does your embedded app calls fb_shutdown() before exit() ?
My "embedded a
On 7/14/21 12:38 PM, Dimitry Sibiryakov wrote:
14.07.2021 11:27, Alex Peshkoff via Firebird-devel wrote:
I'll do a couple more experiments to determine if the problem is
with thread races or library unloading order by OS because I suspect
that on exit they are unloaded in reverse order
As
14.07.2021 12:13, Vlad Khorsun wrote:
Why do you think it does ? Do you have a stack trace ?
Yes. Functions after global destructors are called from fb_shutdown().
Does your embedded app calls fb_shutdown() before exit() ?
My "embedded app" is isql so - yes, it calls fb_shutdown() fr
14.07.2021 12:38, Dimitry Sibiryakov wrote:
14.07.2021 11:27, Alex Peshkoff via Firebird-devel wrote:
I'll do a couple more experiments to determine if the problem is with thread races or library unloading order by OS because I
suspect that on exit they are unloaded in reverse order
As far
14.07.2021 11:27, Alex Peshkoff via Firebird-devel wrote:
I'll do a couple more experiments to determine if the problem is with thread races or
library unloading order by OS because I suspect that on exit they are unloaded in
reverse order
As far as I know yes - reverse.
so trace plugin is
On 7/14/21 12:19 PM, Dimitry Sibiryakov wrote:
14.07.2021 10:51, Alex Peshkoff via Firebird-devel wrote:
What does hex value mean?
"this". Used to identify source object for the line.
I'll do a couple more experiments to determine if the problem is
with thread races or library unloading
14.07.2021 10:51, Alex Peshkoff via Firebird-devel wrote:
What does hex value mean?
"this". Used to identify source object for the line.
I'll do a couple more experiments to determine if the problem is with thread races or
library unloading order by OS because I suspect that on exit they
On 7/13/21 7:22 PM, Dimitry Sibiryakov wrote:
13.07.2021 17:48, Alex Peshkoff via Firebird-devel wrote:
- your process called exit() and due to it plugin is going to be
unloaded, this fact is detected by dtor of UnloadDetectorHelper,
which also calls doClean, but in this case some globals may b
13.07.2021 17:48, Alex Peshkoff via Firebird-devel wrote:
- your process called exit() and due to it plugin is going to be unloaded, this fact is
detected by dtor of UnloadDetectorHelper, which also calls doClean, but in this case some
globals may be already destroyed, you need to manually contr
On 7/13/21 6:32 PM, Dimitry Sibiryakov wrote:
Hello All.
Is doClean() supposed to be guaranteed to be called before plugin
library unloading process?
For Firebird 4 (current snapshot) in embedded I see that it is
called after some global variables of the library are already
destructed,
Hello All.
Is doClean() supposed to be guaranteed to be called before plugin library unloading
process?
For Firebird 4 (current snapshot) in embedded I see that it is called after some global
variables of the library are already destructed, i.e. it is either called from DLLMain or
we h
On 07/21/14 19:08, Dimitry Sibiryakov wrote:
> 01.07.2014 20:05, Alex Peshkoff wrote:
>>> And out of curiosity: what IPluginModule::getModule() is supposed to
>>> return and why it
may be called at all?
>> self
> More interesting question: what is returned by getModule() from i
01.07.2014 20:05, Alex Peshkoff wrote:
>> And out of curiosity: what IPluginModule::getModule() is supposed to
>> return and why it
>> >may be called at all?
>> >
> self
More interesting question: what is returned by getModule() from internal
interfaces,
such as JAttachment?
--
WBR
On 07/01/14 22:40, Dimitry Sibiryakov wrote:
And out of curiosity: what IPluginModule::getModule() is supposed to
return and why it
may be called at all?
>> self
> But calling code already has this pointer. What's the point?
>
Because all our interfaces are derived f
01.07.2014 20:05, Alex Peshkoff wrote:
>>> You are wrong - module may (and does - Win_Sspi) contain >1 factories.
>> > Which means that each of them can perform its part of cleanup or only
>> > one of them can
>> >do cleanup - it is up to plugin developer. I still see no point in single
>> >c
On 07/01/14 20:15, Dimitry Sibiryakov wrote:
> 01.07.2014 18:06, Alex Peshkoff wrote:
>> On 07/01/14 16:36, Dimitry Sibiryakov wrote:
01.07.2014 14:24, Alex Peshkoff wrote:
>> 1. It must be single instance per module, therefore may be used as an
>> unique marker for it.
I saw
01.07.2014 18:06, Alex Peshkoff wrote:
> On 07/01/14 16:36, Dimitry Sibiryakov wrote:
>> >01.07.2014 14:24, Alex Peshkoff wrote:
>>> >>1. It must be single instance per module, therefore may be used as an
>>> >>unique marker for it.
>> > I saw nowhere this requirement is written.
>> > Plugi
On 07/01/14 16:36, Dimitry Sibiryakov wrote:
> 01.07.2014 14:24, Alex Peshkoff wrote:
>> 1. It must be single instance per module, therefore may be used as an
>> unique marker for it.
> I saw nowhere this requirement is written.
> Plugin factory, BTW has the same quality, so I really don't
01.07.2014 14:24, Alex Peshkoff wrote:
> 1. It must be single instance per module, therefore may be used as an
> unique marker for it.
I saw nowhere this requirement is written.
Plugin factory, BTW has the same quality, so I really don't see a reason for
a separate
class.
Every plugin m
On 07/01/14 15:47, Dimitry Sibiryakov wrote:
> 01.07.2014 10:34, Alex Peshkoff wrote:
>> Interface IPluginModule is
>> not only for providing doClean function, it's a collection of
>> functionalities required for module, not instance.
> I see only doClean(), getVersion() and getModule(). What f
01.07.2014 10:34, Alex Peshkoff wrote:
> Interface IPluginModule is
> not only for providing doClean function, it's a collection of
> functionalities required for module, not instance.
I see only doClean(), getVersion() and getModule(). What functionality I
missed?
--
WBR, SD.
--
On 07/01/14 11:35, Dimitry Sibiryakov wrote:
> 01.07.2014 8:47, Alex Peshkoff wrote:
>> getMo_g_ule() is really missing, but getMo_d_ule(), returning pointer to
>> IPluginModule, is present in MasterImplementation::upgradeInterface()
> So far there is only one version, upgradeInterface() is not
01.07.2014 8:47, Alex Peshkoff wrote:
> getMo_g_ule() is really missing, but getMo_d_ule(), returning pointer to
> IPluginModule, is present in MasterImplementation::upgradeInterface()
So far there is only one version, upgradeInterface() is not ever called. And
even there
returned module is n
On 06/30/14 19:25, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Currently function getMogule() and IPluginModule itself is never used in
> code. May be
> it is not too late yet to kill the call and the class to decrease complexity
> of
> third-party plugin development?..
>
getMo_g_ule() i
Hello, All.
Currently function getMogule() and IPluginModule itself is never used in
code. May be
it is not too late yet to kill the call and the class to decrease complexity of
third-party plugin development?..
--
WBR, SD.
---
41 matches
Mail list logo
