This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1.7.0-60] crash on exit on c++ program (octave)


On Fri, Aug 21, 2009 at 04:54:45PM +0100, Dave Korn wrote:
>Christopher Faylor wrote:
>> On Fri, Aug 21, 2009 at 10:57:42AM +0200, Corinna Vinschen wrote:
>>> On Aug 20 21:12, Dave Korn wrote:
>>>> Dave Korn wrote:
>>>>>   We should probably make running the dtors idempotent, or unlink each dll
>>>>> from the dll_list as we go.  I need to think about this for a little while,
>>>>> more later.
>>>>   The solution could be as simple as this.  Just don't call dtors for dlopen'd
>>>> DLLs when we run the global dll dtors.  If the application dlcloses them,
>>>> their dtors get run then.  If it doesn't, they'll be run much later when the
>>>> dlopen'd module receives DLL_PROCESS_DETACH as everything is being closed.
>>>> Only thing I'm wondering about is if we shouldn't forcibly dlclose any
>>>> left-over modules as part of the dtors sequence so that they run before the
>>>> newlib i/o shutdown.  Anyone got an opinion?
>>> I think the dlclose call should be enforced for left-over modules.  We
>>> can use the below as temporary patch to avoid the crash for now.
>> 
>> I did some debugging on this last night.  I made what seemed to be an
>> obvious fix of running the destructors before the dll was unloaded and
>> still got a segv.  I didn't have time to track it down further but I
>> don't like the fact that destructors for dlopened modules cause a crash.
>> 
>> Dave's change seems wrong to me.  I don't know why we'd avoid running
>> destructors.  We should just not run them after the module has been
>> unloaded.
>
>That isn't the problem.  The dtors were being run *twice*.

How is that not the problem?  We end up avoiding generally running
destructors for dynamically loaded shared libraries whether they need to
be run or not.

I just added a field to the dll table to record when a dll has destructors
to run.  Testing that before running the destructor seems to solve the
problem.  This is now in CVS and the latest snapshot.

Thanks for the patch and especially for the analysis.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]