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
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
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
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
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(),
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
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
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
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
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 -
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
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
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()
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
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
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
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
27 matches
Mail list logo
