On Tue, Feb 02, 2010 at 03:30:10PM +, Andrew West wrote:
>On 02/02/2010 15:16, Christopher Faylor wrote:
>> On Tue, Feb 02, 2010 at 09:36:54AM +, Andrew West wrote:
>>
>>> O.k. I've changed remove_dll_atexit to;
>>>
>>> remove_dll_atexit (const dll *d)
>>> {
>>>
>>> unsigned char
On 02/02/2010 15:16, Christopher Faylor wrote:
> I've gotten rid of remove_dll_atexit and implemented Dave's other idea of
> specifically calling cxa_atexit when atexit is called from a DLL. I realize
> this morning that this might require some additional tweaking to preserve
> the same order of
On 02/02/2010 15:16, Christopher Faylor wrote:
On Tue, Feb 02, 2010 at 09:36:54AM +, Andrew West wrote:
O.k. I've changed remove_dll_atexit to;
remove_dll_atexit (const dll *d)
{
unsigned char *dll_beg = (unsigned char *) d->handle + 0x1000;
unsigned char *dll_end = (unsigned
On Tue, Feb 02, 2010 at 09:36:54AM +, Andrew West wrote:
>On 01/02/2010 21:24, Dave Korn wrote:
>> On 01/02/2010 20:45, Andrew wrote:
>>
>>
>>> I'm not looking to submit a patch to fix this, I'll leave that up to the
>>> professionals who have a better idea about the whole picture. It's jus
On 02/02/2010 08:35, Andrew West wrote:
>>> Looking at one of the libraries in my code that fails I get ( with the
>>> atexit at 0x78351c9 )
>>>
>>> remove_dll_atexit;
>>> m.AllocationBase = 0x782
>>> m.AllocationBase + m.RegionSize = 0x7824000
> I've attached the objdump -h output. Looks lik
On 01/02/2010 21:24, Dave Korn wrote:
On 01/02/2010 20:45, Andrew wrote:
I'm not looking to submit a patch to fix this, I'll leave that up to the
professionals who have a better idea about the whole picture. It's just
I've hit a brick wall with my code with this bug so I'm looking for some
On 01/02/2010 22:44, Dave Korn wrote:
On 01/02/2010 17:35, Andrew West wrote:
But the atexit function is registered at 0x706c10f0. Changing
AllocationBase to BaseAddress worked for my test case out of pure luck,
with my larger libraries it still failed.
I've managed to convince my
On 01/02/2010 17:35, Andrew West wrote:
> But the atexit function is registered at 0x706c10f0. Changing
> AllocationBase to BaseAddress worked for my test case out of pure luck,
> with my larger libraries it still failed.
I've managed to convince myself it's right actually.
> Looking at one of
On 01/02/2010 20:45, Andrew wrote:
> I'm not looking to submit a patch to fix this, I'll leave that up to the
> professionals who have a better idea about the whole picture. It's just
> I've hit a brick wall with my code with this bug so I'm looking for some
> work arounds for myself.
No, real
On 01/02/10 19:28, Dave Korn wrote:
On 01/02/2010 17:51, Christopher Faylor wrote:
On Mon, Feb 01, 2010 at 12:46:11PM -0500, Christopher Faylor wrote:
Cribbing from the gdb source code, it looks like they use BaseAddrees +
0x1000 for the start point and then call GetModuleInformat
On 01/02/2010 17:51, Christopher Faylor wrote:
> On Mon, Feb 01, 2010 at 12:46:11PM -0500, Christopher Faylor wrote:
>>> Cribbing from the gdb source code, it looks like they use BaseAddrees +
>>> 0x1000 for the start point and then call GetModuleInformation to workout
>>> the size of the module
On Mon, Feb 01, 2010 at 12:46:11PM -0500, Christopher Faylor wrote:
>On Mon, Feb 01, 2010 at 05:35:10PM +, Andrew West wrote:
>>On 01/02/2010 16:26, Christopher Faylor wrote:
>>> Could you clarify? Are you saying that your test case still failed?
>>>
>>
>>With the change you provided my te
On 01/02/2010 17:35, Andrew West wrote:
> Cribbing from the gdb source code, it looks like they use BaseAddrees +
> 0x1000 for the start point and then call GetModuleInformation to workout
> the size of the module. I'm currently trying this out in dll_init.cc but
> for some reason GetCurrentProce
On Mon, Feb 01, 2010 at 05:35:10PM +, Andrew West wrote:
>On 01/02/2010 16:26, Christopher Faylor wrote:
>> Could you clarify? Are you saying that your test case still failed?
>>
>
>With the change you provided my test still failed, but changing
>m.AllocationBase to m.BaseAddress it worke
On 01/02/2010 16:26, Christopher Faylor wrote:
Could you clarify? Are you saying that your test case still failed?
With the change you provided my test still failed, but changing
m.AllocationBase to m.BaseAddress it worked.
Unfortunately it only worked for that test cash, on trying it wit
On Mon, Feb 01, 2010 at 11:46:55AM +, Andrew West wrote:
>On 29/01/2010 18:45, Christopher Faylor wrote:
>> On Fri, Jan 29, 2010 at 02:30:48PM +, Andrew West wrote:
>>
>>> On 29/01/2010 13:08, Dave Korn wrote:
>>>
On 28/01/2010 11:21, Andrew West wrote:
> I s
On 01/02/2010 11:46, Andrew West wrote:
> I checked out the changes and it still crashed for me. Digging into it
> the destructor for testlib fell outside of dll_end ( m.AllocationBase +
> m.RegionSize ). On a whim I change m.AllocationBase to m.BaseAddress and
> that seemed to fix it for me! The
On 29/01/2010 18:45, Christopher Faylor wrote:
On Fri, Jan 29, 2010 at 02:30:48PM +, Andrew West wrote:
On 29/01/2010 13:08, Dave Korn wrote:
On 28/01/2010 11:21, Andrew West wrote:
I seem to be having a problem with dlclose not calling the destructors
of statically decla
On Fri, Jan 29, 2010 at 08:32:35PM +, Andy Koppe wrote:
>Christopher Faylor:
>> Andrew West:
>>>O.k. I'll check out the changes on Monday, but one minor point.
>>>Shouldn't the atexit stuff be run after all the destructors have run?
>>
>> Not if the output from the linux version of your program
Christopher Faylor:
> Andrew West:
>>O.k. I'll check out the changes on Monday, but one minor point.
>>Shouldn't the atexit stuff be run after all the destructors have run?
>
> Not if the output from the linux version of your program is to be
> believed. I originally had the atexit stuff run after
On Fri, Jan 29, 2010 at 07:17:13PM +, Andrew West wrote:
>O.k. I'll check out the changes on Monday, but one minor point.
>Shouldn't the atexit stuff be run after all the destructors have run?
Not if the output from the linux version of your program is to be
believed. I originally had the ate
On 29/01/10 18:45, Christopher Faylor wrote:
On Fri, Jan 29, 2010 at 02:30:48PM +, Andrew West wrote:
On 29/01/2010 13:08, Dave Korn wrote:
On 28/01/2010 11:21, Andrew West wrote:
I seem to be having a problem with dlclose not calling the destructors
of statically declare
On Fri, Jan 29, 2010 at 02:30:48PM +, Andrew West wrote:
>On 29/01/2010 13:08, Dave Korn wrote:
>> On 28/01/2010 11:21, Andrew West wrote:
>>>I seem to be having a problem with dlclose not calling the destructors
>>>of statically declared variables. I've attached a simple test case
>>>which I
On 29/01/2010 15:28, Andrew West wrote:
> Ah o.k. So is there any documentation on how Cygwin should do things
> differently?
Only the source so far, but I'll add some when I fix this.
> Should atexit be used for both executables and library
> static destructors? Is there a reason for not usi
On 29/01/2010 15:23, Dave Korn wrote:
On 29/01/2010 14:30, Andrew West wrote:
Which brings me on to the bigger problem, the static variables are
registered with atexit rather than with __cxa_atexit which seems to be a
violation of the C++ standard (1).
That's not the C++ standard;
On 29/01/2010 14:30, Andrew West wrote:
> Which brings me on to the bigger problem, the static variables are
> registered with atexit rather than with __cxa_atexit which seems to be a
> violation of the C++ standard (1).
That's not the C++ standard; that is part of the cxx-abi. Since so much o
On 29/01/2010 13:08, Dave Korn wrote:
On 28/01/2010 11:21, Andrew West wrote:
I seem to be having a problem with dlclose not calling the destructors
of statically declared variables. I've attached a simple test case which
I compile as follows;
Thanks for the report and the STC; thi
On 28/01/2010 11:21, Andrew West wrote:
> I seem to be having a problem with dlclose not calling the destructors
> of statically declared variables. I've attached a simple test case which
> I compile as follows;
Thanks for the report and the STC; this should work. I'll take a look at it
over th
28 matches
Mail list logo
