first time on win ME.
Regards,
Steven
void
dll_list::load_after_fork (HANDLE parent, dll *first)
{
in_forkee = 1;
dll d;
void *next = first;
while (next)
{
DWORD nb;
/* Read the dll structure from the parent. */
if (!ReadProcessMemory (parent, next, &d, sizeof (d
Chris,
On Fri, Dec 07, 2001 at 08:02:22PM -0500, Christopher Faylor wrote:
> A rebase utility for cygwin would be pretty nice, I think.
Attached is the beginning of a rebase utility. It is modeled after the
MS one:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/per
- Original Message -
From: "Jason Tishler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 13, 2001 12:07 AM
Subject: rebase utility (was Re: dll_list::load_after_fork() blues ...)
> Chris,
>
> On Fri, Dec 07, 2001 at 08:02:22PM
On Wed, Dec 12, 2001 at 08:07:59AM -0500, Jason Tishler wrote:
> On Fri, Dec 07, 2001 at 08:02:22PM -0500, Christopher Faylor wrote:
> > A rebase utility for cygwin would be pretty nice, I think.
>
> Attached is the beginning of a rebase utility. It is modeled after the
> MS one:
>
> [snip]
Oo
On Wed, Dec 12, 2001 at 08:57:44AM -0500, Jason Tishler wrote:
> On Mon, Dec 10, 2001 at 11:52:08AM -0500, Norman Vine wrote:
> > Michael Hudson writes:
> > >FWIW, and I don't know how much that is, all tests pass if I link _socket
> > >statically. Oh, and this is building without threads, it see
in Python problems
are synchronized with Python releases. Sigh...
A few months ago, I did some investigation on this problem. What I
learned from adding some printfs to dll_list::load_after_fork() was
that the DLL in question was *already* remapped from the its preferred
image-base in the pa
Your results are enough for me Jason - I'm happy to include this in
setup in some form.
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygw
On Wed, Dec 19, 2001 at 08:33:50AM +1100, Robert Collins wrote:
>Your results are enough for me Jason - I'm happy to include this in
>setup in some form.
Nice job, Jason. Thanks for following this through.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:
Jason Tishler writes:
>
>I believe that I have found a rebase solution to the Cygwin fork()
>problem that has been causing Cygwin Python some grief lately. I added
>an offset option to the attached rebase tool. If I spread the DLLs out
>by an extra 0x1, then the fork() problem seems to be mi
Chris,
On Tue, Dec 18, 2001 at 10:28:13PM -0500, Christopher Faylor wrote:
> On Wed, Dec 19, 2001 at 08:33:50AM +1100, Robert Collins wrote:
> >Your results are enough for me Jason - I'm happy to include this in
> >setup in some form.
>
> Nice job, Jason. Thanks for following this through.
You
y, December 21, 2001 7:51 AM
Subject: Re: cygwin fork() rebase solution (was Re:
dll_list::load_after_fork() blues ...)
> Chris,
>
> On Tue, Dec 18, 2001 at 10:28:13PM -0500, Christopher Faylor wrote:
> > On Wed, Dec 19, 2001 at 08:33:50AM +1100, Robert Collins wrote:
> >
Chris,
On Sat, Dec 22, 2001 at 10:22:37AM -0500, Chris McDonough wrote:
> FYI, Zope was broken under out-of-the-box Cygwin 1.3.6 because of the fork
> issue. The rebase solution allows Zope to work again.
>
> Many thanks,
You are very welcome! Thanks for taking the time to see if this solutio
Jason Tishler wrote:
>>
>>building 'gdbm' extension
>>gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -I.
>-I/cygdrive/e/Python-2.2b2/./Include -I/usr/local/include -IInclude/ -c
>/cygdrive/e/Python-2.2b2/Modules/gdbmmodule.c -o
>build/temp.cygwin-1.3.5-i686-2.2/gdbmmodule.o
>>e:\buildpy
On Fri, Dec 07, 2001 at 07:54:32PM -0500, Charles Wilson wrote:
>Anyway, they had a problem after upgrading to a new cygwinish dll
>(cygncurses?? I think) w.r.t. load-on-fork. There's no way setup/rebase
>can be used to avoid that problem a_priori...is there? (As I recall,
>the person did a 'han
- Original Message -
From: "Norman Vine" <[EMAIL PROTECTED]>
> FWIW
> I just tried patching Cygwin's dlopen() function to always rebase
dll's
> on loading with a 'slightly hacked to force rebasing' version of
Interesting idea. Unfortunately it only covers the dlopened dll's - and
we need
The ASSume principle applies once again...
On Thu, Dec 06, 2001 at 12:44:26PM -0500, Jason Tishler wrote:
> I have just reproduced this build problem with Python 2.2b2 too. However,
> I don't believe that it is related to the particular Python version one
> attempts to build.
Actually, setup.py
On Thu, 6 Dec 2001, Charles Wilson wrote:
> Jason Tishler wrote:
>
>
> >>
> >>building 'gdbm' extension
> >>gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -I.
>-I/cygdrive/e/Python-2.2b2/./Include -I/usr/local/include -IInclude/ -c
>/cygdrive/e/Python-2.2b2/Modules/gdbmmodule.c -o
>bui
t;[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; "Cygwin" <[EMAIL PROTECTED]>
Sent: Friday, December 07, 2001 9:50 AM
Subject: Re: dll_list::load_after_fork() blues (was Re:
[ python-Bugs-489709 ] Building Fails ...)
> On Thu, 6 Dec 2001, Charles Wilson wrote:
>
> > Jas
Dave,
On Fri, Dec 07, 2001 at 10:03:24AM -0500, David Abrahams wrote:
> FWIW, Jason's patch worked for me,
Thanks for the feedback.
> except for curses of course which seems to be broken in cygwin.
The above is a known problem, see the following for details:
http://sources.redhat.com/ml/c
- Original Message -
From: "Charles Wilson" <[EMAIL PROTECTED]>
> > The above occurs during Cygwin's fork() when the Cygwin DLL cannot
> > load a DLL to the same address in the child that it had in the
parent.
> > I have seen this during Python 2.1.1 regression tests with threads
> > enabl
Robert Collins wrote:
> > Part of the problem may be that cyggdbm.dll was built with
> > --auto-image-base. It was later demonstrated that this can cause
> > problems with fork; you're better off just letting ld assign the
> default
> > dllbase, which means that EVERY process will remap the dll
Robert Collins writes:
>
>- Original Message -
>From: "Charles Wilson" <[EMAIL PROTECTED]>
>> > The above occurs during Cygwin's fork() when the Cygwin DLL cannot
>> > load a DLL to the same address in the child that it had in the parent.
>> > I have seen this during Python 2.1.1 regressio
- Original Message -
From: "Charles Wilson" <[EMAIL PROTECTED]>
> > Yes. There is actually a longer term solution... which is to
'rebase'
> > every cygwin linked .dll on a particular system to not conflict with
> > each other - which has to be done by setup.exe.
>
> Yes, but only with the
iminate the possibility of cockpit
error on my part?
Does anyone understand why the DLLs are being rebased even though there
theoretically is no chance of a base address conflict anymore?
Thanks,
Jason
test_popen2
0 [main] python 648 dll_list::load_after_fork: remap failed for
C:\home\jtis
;
<[EMAIL PROTECTED]>
Sent: Monday, December 10, 2001 11:46 PM
Subject: Re: dll_list::load_after_fork() blues (was Re: [
python-Bugs-489709 ] Building Fails ...)
> On Sat, Dec 08, 2001 at 10:08:14AM +1100, Robert Collins wrote:
> > Yes. There is actually a longer term solution.
On Mon, 10 Dec 2001, Jason Tishler wrote:
> Unfortunately, when I run the complete Python regression test, I still
> get the same three test failures as reported by Michael without rebasing:
>
> test_popen2
> test_pty
> test_socket
>
> When I run these tests individually (i.e., not
Rob,
On Mon, Dec 10, 2001 at 11:42:01PM +1100, Robert Collins wrote:
> Possibly because the cygwin heap is getting allocated across where those
> .dll's would go.
That is what I figured. Any suggestions on a good address to use during
the rebasing?
Thanks,
Jason
--
Unsubscribe info: http
Michael Hudson writes:
>
>On Mon, 10 Dec 2001, Jason Tishler wrote:
>
>> Unfortunately, when I run the complete Python regression test, I still
>> get the same three test failures as reported by Michael without rebasing:
>>
>> test_popen2
>> test_pty
>> test_socket
>>
>> When I run the
On Mon, Dec 10, 2001 at 11:52:08AM -0500, Norman Vine wrote:
> Michael Hudson writes:
> >FWIW, and I don't know how much that is, all tests pass if I link _socket
> >statically. Oh, and this is building without threads, it seems. I'll do
> >a new build with threads and see if anything changes, b
- Original Message -
From: "Jason Tishler" <[EMAIL PROTECTED]>
> Rob,
>
> On Mon, Dec 10, 2001 at 11:42:01PM +1100, Robert Collins wrote:
> > Possibly because the cygwin heap is getting allocated across where
those
> > .dll's would go.
>
> That is what I figured. Any suggestions on a go
- Original Message -
From: "Jason Tishler" <[EMAIL PROTECTED]>
> - cygwin1.dll: since I believe that it relies on being based
> at 0x6100
It does not rely on any base address per se. It *does* reply on the base
address being consistent between forked/spawned and
Rob,
On Sun, Dec 16, 2001 at 07:26:37PM +1100, Robert Collins wrote:
> From: "Jason Tishler" <[EMAIL PROTECTED]>
> > - cygwin1.dll: since I believe that it relies on being based
> > at 0x6100
>
> It does not rely on any base address per se. It *does* reply on the base
>
> By "process explorer," do you mean Process Explorer (aka HandleEx)
from
> Sysinternals?
Yes.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://c
Michael,
On Fri, Dec 07, 2001 at 03:12:48PM +, Michael Hudson wrote:
> Michael Hudson <[EMAIL PROTECTED]> writes:
> > Your patch helps by the way. I tried building without threads -- that
> > didn't.
>
> OTOH, some tests crash:
>
> 3 tests failed:
> test_popen2 test_pty test_socket
I
34 matches
Mail list logo
