On 02/03/2018 09:14, ignace danneels wrote:
I’m very sorry to contact you, but I may need some support to solve
the following problem.
My company is creating automotive software, and our controllers are
using a bootloader which we buy from an external supplier.
In general on this mailing
On Tue, Jul 17, 2012 at 9:37 PM, Andrew DeFaria wrote:
On 7/17/2012 6:56 PM, Reini Urban wrote:
On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote:
Is there a workaround for the problem mentioned in
http://cygwin.com/ml/cygwin/2006-11/msg00580.html? I suddenly started
getting this error
On 7/18/2012 8:04 AM, Reini Urban wrote:
On Tue, Jul 17, 2012 at 9:37 PM, Andrew DeFaria wrote:
On 7/17/2012 6:56 PM, Reini Urban wrote:
On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote:
Is there a workaround for the problem mentioned in
On Wed, Jul 18, 2012 at 2:15 PM, Andrew DeFaria wrote:
Odd. Somebody seems to have put something in my Views directory - a
directory I normally use for Clearcase views. But what's in there is not a
Clearcase view! And it contained several cygwin1.dll's. So I blew it way.
Sorry for the
On 7/18/2012 11:38 AM, Earnie Boyd wrote:
On Wed, Jul 18, 2012 at 2:15 PM, Andrew DeFaria wrote:
Odd. Somebody seems to have put something in my Views directory - a
directory I normally use for Clearcase views. But what's in there is not a
Clearcase view! And it contained several cygwin1.dll's.
On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote:
Is there a workaround for the problem mentioned in
http://cygwin.com/ml/cygwin/2006-11/msg00580.html? I suddenly started
getting this error like every other time I run perl.
perlrebase
--
Problem reports:
On 7/17/2012 6:56 PM, Reini Urban wrote:
On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote:
Is there a workaround for the problem mentioned in
http://cygwin.com/ml/cygwin/2006-11/msg00580.html? I suddenly started
getting this error like every other time I run perl.
perlrebase
When I run
On Mar 1 17:44, Charles Wilson wrote:
On 3/1/2012 7:14 AM, Corinna Vinschen wrote:
Hmm. cygcheck loads the Cygwin DLL dynamically. It does not depend on
any other Cygwin distro DLL. But it's started from a Cygwin parent. So
the loaded CYgwin DLL checks the layout just like it had been
On 3/2/2012 3:59 AM, Corinna Vinschen wrote:
On Mar 1 17:44, Charles Wilson wrote:
Is there some workaround that could be used?
Rebase pghook.dll.
Oh, well, yeah -- that would work if I were allowed to do so. However,
remember paranoid corporate IT policies? Avecto Privilege Guard is
On Mar 1 05:56, Heiko Elger wrote:
I can agree having some times same error on multiple machines (win7/64) - but
always when running perl.
1 [main] perl (7796) c:\programme\cygwin\bin\perl.exe: *** fatal error -
cygheap base mismatch detected - 0xE158D0
/0xEF58D0.
I don't know what's
On Feb 29 14:30, Charles Wilson wrote:
I've been running into a strange error lately (that is, I first
noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9.
It persists on 1.7.11). cygcheck -- and *only* cygcheck -- is reporting
a cygheap base mismatch but only on an XP64
On Thu, Mar 1, 2012 at 11:51 AM, Corinna Vinschen wrote:
On Feb 29 14:30, Charles Wilson wrote:
I've been running into a strange error lately (that is, I first
noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9.
It persists on 1.7.11). cygcheck -- and *only* cygcheck -- is
On Mar 1 11:59, marco atzeri wrote:
On Thu, Mar 1, 2012 at 11:51 AM, Corinna Vinschen wrote:
On Feb 29 14:30, Charles Wilson wrote:
I've been running into a strange error lately (that is, I first
noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9.
It persists on
On 3/1/2012 7:14 AM, Corinna Vinschen wrote:
Hmm. cygcheck loads the Cygwin DLL dynamically. It does not depend on
any other Cygwin distro DLL. But it's started from a Cygwin parent. So
the loaded CYgwin DLL checks the layout just like it had been linked
against. And apparently it gets
On 2/29/2012 8:30 PM, Charles Wilson wrote:
I've been running into a strange error lately (that is, I first
noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9.
It persists on 1.7.11). cygcheck -- and *only* cygcheck -- is reporting
a cygheap base mismatch but only on an XP64
I can agree having some times same error on multiple machines (win7/64) - but
always when running perl.
1 [main] perl (7796) c:\programme\cygwin\bin\perl.exe: *** fatal error -
cygheap base mismatch detected - 0xE158D0
/0xEF58D0.
This problem is probably due to using incompatible versions of
On Thu, Mar 1, 2012 at 6:56 AM, Heiko Elger wrote:
I can agree having some times same error on multiple machines (win7/64) - but
always when running perl.
1 [main] perl (7796) c:\programme\cygwin\bin\perl.exe: *** fatal error -
cygheap base mismatch detected - 0xE158D0
/0xEF58D0.
This
On Nov 22 12:36, Joseph Koenig wrote:
Congrats on figuring the problem out so quickly. Forgive my lack of
familiarity with the cygwin development process (and cygwin in general),
but as you've seemingly isolated root cause, do you feel that a point
fix should be forthcoming shortly or do you
On Nov 17 18:29, Joseph Koenig wrote:
DISCLAIMER: Yes, I realize Vista is not officially supported. If anything I
hope this e-mail will end up in the archives to prevent other uses who see
this same problem from wasting time if there is no war available.
I have successfully used cygwin on
: Wednesday, November 22, 2006 5:04 AM
To: cygwin@cygwin.com
Subject: Re: cygheap base mismatch detected - only on Vista x64, not
seen on Vista x86
On Nov 17 18:29, Joseph Koenig wrote:
DISCLAIMER: Yes, I realize Vista is not officially supported. If
anything I hope this e-mail will end up
On 11/17/2006, Joseph Koenig wrote:
Has anyone seen a similar error? Has anyone got a clue as to WAR? Perhaps a
rebase? I have tried disabling DEP for bash and ls as I am worried about
address space randomization causing problems with fork, but that exists in
Vista32 and I don't have problems
I'm happy to report that I was finally able to run a
successful rebaseall (after tracking down and stopping
the pesky service that was using Oracle DLLs and restarting
itself every time I killed it in the Task Manager).
Now that the Oracle DLLs have been rebased, the app runs.
I'm now into other
On Fri, Feb 24, 2006 at 02:36:19PM -0600, Dill, Jens wrote:
I did make the changes to rebase suggested by Mark Geisert, and I will
be forwarding my updated source file to Jason Tishler for him to take
a look at.
Please send them in the form of a patch against the latest source.
Thanks,
Jason
Mark Geisert writes:
I can't do more without learning a lot more than I currently know
about the internals of DLLs and of rebase.
You have the problem Oracle DLLs, we don't :-) so you might be the
only one who can ultimately solve the problem. But see below...
Right. But you (collectively)
Dill, Jens (END-CHI) wrote:
I have found Microsoft's Platform SDK, and have used the VaDump utility
to find out where all the DLL's are loaded. Here is what it says about
my app (sorted into ascending order of memory address):
FYI, to check the ImageBase of a given DLL you can just use
Brian Dessent writes:
I think your best bet would be to keep poking at rebase to see if you
can't actually rebase the Oracle DLLs.
(2) Rebase the CygWin DLL so that it loads by default into a
space not used in either memory map (I'd need help in
choosing such a space). I've tried
On Tue, Feb 21, 2006 at 09:25:45AM -0600, Dill, Jens (END-CHI) wrote:
(2) Rebase the CygWin DLL so that it loads by default into a
space not used in either memory map (I'd need help in
choosing such a space). I've tried both Microsoft's
rebase and CygWin's rebase, but the
Jason, are you following this?
On Sat, Feb 18, 2006 at 09:12:02PM -0600, Dill, Jens (END-CHI) wrote:
We are finally zeroing in on the problem.
Mark Geisert writes:
The code at /src/rebase-2.3.1/rebase.c:255 assumes the signature is at
offset 0x80
in the image. This was true in the early
On Tue, Feb 21, 2006 at 11:18:40AM -0800, Yitzchak Scott-Thoennes wrote:
Jason, are you following this?
Not very closely. Sorry, but cycles are very scarce right now.
However, I did note the following from Mark:
On Sat, Feb 18, 2006 at 01:39:30AM -0800, Mark Geisert wrote:
The code at
On Sat, Feb 18, 2006 at 09:12:02PM -0600, Dill, Jens (END-CHI) wrote:
It seems that there is indeed more to it. I did make the obvious
change and reran rebaseall. The message I got from the first Oracle
DLL it encountered was:
ReBaseImage
On Sat, Feb 18, 2006 at 09:12:02PM -0600, Dill, Jens (END-CHI) wrote:
So, I have a workaround of sorts. I can have my script launch my app
by writing the command line to a .bat file and executing it. Definitely
not something I can use to convince my management to go with CygWin.
Wouldn't
On Sat, 18 Feb 2006, Dill, Jens (END-CHI) wrote:
[...]
I finally found where to get the rebase source, and verified that in
fact, what Mark noticed in 2.3.1 is still true in 2.4.2-1. I can
easily make the obvious fix and change the is_rebaseable function to
get the pe_signature_offset out of
On Sun, Feb 19, 2006 at 09:02:10PM -0800, Mark Geisert wrote:
Forgive me for possibly reading more into your text than you intended
and thus responding inappropriately, but, Cygwin is an all-volunteer
and essentially non-managed project. (No offense Christopher :-) There
are no *guarantees* about
We are finally zeroing in on the problem.
Mark Geisert writes:
The code at /src/rebase-2.3.1/rebase.c:255 assumes the signature is at
offset 0x80
in the image. This was true in the early Windows days but has long since
been
generalized. The technique nowadays is to obtain the short integer
On 16 February 2006 23:17, Dill, Jens (END-CHI) wrote:
More test results:
Right, thanks for giving us something we can actually get our teeth into...
it would really have been helpful to bring out some of this information a bit
earlier in the thread, like in the very first post for instance,
Dave Korn writes:
Right, thanks for giving us something we can actually get our teeth
into...
it would really have been helpful to bring out some of this information a
bit
earlier in the thread, like in the very first post for instance, but
better
late than never!
Sorry I didn't send
I wrote:
Could I
fix the problem by providing a stripped-down app that links all
the DLLs and and all the same static libraries, but does nothing
but launch a shell, which can then be used to launch the real app?
Nope, didn't work. Got the same message:
2 [main] ? (-5768)
On 15 February 2006 22:23, Jens Dill wrote:
Dave Korn dave.korn at artimi.com writes:
Original Message
From: Andreas Heckel
Sent: 07 April 2005 11:13
^
Dave:
What you write makes it appear that CygWin simply will not support
large executables that
On Thu, Feb 16, 2006 at 01:17:07AM -0600, Dill, Jens (END-CHI) wrote:
Christopher Faylor wrote:
On Wed, Feb 15, 2006 at 10:22:30PM +, Jens Dill wrote:
What you write makes it appear that CygWin simply will not support
large executables that reference the CygWin DLL and are also launched
On 16 February 2006 07:17, Dill, Jens (END-CHI) wrote:
Unfortunately for me, (e) is impractical. It's not clear whether
it is my source code or CygWin's that I need to fix,
Have you actually *tried* this application of yours under Cygwin and
discovered that it indeed *is* one of the rare
Dave Korn writes:
On 15 February 2006 22:23, Jens Dill wrote:
Jens Dill writes:
Original Message
From: Andreas Heckel
Sent: 07 April 2005 11:13
^
Dave:
What you write makes it appear that CygWin simply will not support
large executables that
Dave Korn writes:
Unfortunately for me, (e) is impractical. It's not clear whether
it is my source code or CygWin's that I need to fix,
Have you actually *tried* this application of yours under Cygwin and
discovered that it indeed *is* one of the rare ones that actually runs
into
this
On 16 February 2006 18:03, Dill, Jens (END-CHI) wrote:
I can't make this agree with the facts in front of me.
If it has to do with executables that allocate massive amounts
of heap space, then how does the message appear before the
application even starts, before it has a chance to allocate
Dill, Jens (END-CHI) wrote:
Dave Korn writes:
Unfortunately for me, (e) is impractical. It's not clear whether
it is my source code or CygWin's that I need to fix,
Have you actually *tried* this application of yours under Cygwin and
discovered that it indeed *is* one of the rare ones that
More test results:
I can run tests in which I allocate static arrays of increasingly
large size, and I hit the cygheap base problem *exactly* when I
try to make an array bigger than 1.5 Gb.
This still happens reliably, and note that I can declare an array
of *exactly* 1.5 Gb, and load and run
Dave Korn dave.korn at artimi.com writes:
Original Message
From: Andreas Heckel
Sent: 07 April 2005 11:13
Since I read that the error has something do with putting the cygwin1.dll
in a certain memory space, I am wondering, if my prog is allocating too
much memory (big
On Wed, Feb 15, 2006 at 10:22:30PM +, Jens Dill wrote:
What you write makes it appear that CygWin simply will not support
large executables that reference the CygWin DLL and are also launched
from a CygWin shell. I can't believe that nobody has found a better
workaround than:
(a) not using
Christopher Faylor wrote:
On Wed, Feb 15, 2006 at 10:22:30PM +, Jens Dill wrote:
What you write makes it appear that CygWin simply will not support
large executables that reference the CygWin DLL and are also launched
from a CygWin shell. I can't believe that nobody has found a better
Hi,
- Original Message -
From: Mark Hadfield [EMAIL PROTECTED]
The solutions:
- Try the -mno-cygwin switch (thus creating a non-Cygwin executable).
Be aware that you may need to recompile any external libraries.
I tried this and it works for now, Thanx! :-) I should have come to
Original Message
From: Andreas Heckel
Sent: 07 April 2005 11:13
Since I read that the error has something do with putting the cygwin1.dll
in a certain memory space, I am wondering, if my prog is allocating too
much memory (big arrays) or in bad way.
I am not an expert in these
Andreas Heckel wrote:
Hello all,
I know there were a lot of similar questions to this point in the past,
but I didn't find a answer to my problem:
I get the error message:
---
v:\julian\TRAJ\Traj2.xi686 (2116): *** cygheap base mismatch detected -
0x6180/0x7214.
This problem is probably
51 matches
Mail list logo
